On Dec 21, 2005, at 12:10 PM, Randal L. Schwartz wrote:
"Fred" == Fred Moyer <[EMAIL PROTECTED]> writes:
Fred> Can you explain a bit more why using keep-alives to the
backend is not
Fred> a good thing? I've always been under the impression from
conference
Fred> lectures and literature th
: "Perrin Harkins" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, December 22, 2005 2:44 AM
Subject: Re: go crazy with me
> > Okay, so you basically run two daemons -- mod_perl, and a separate
> > multiplexing one -- to handle this? Did you investigate what would be
> > i
I have Apache 1.33 on my front end and an .htaccess file with the
following
RewriteRule
^(.*)habitat[/]?$ http://perl.habitatlife.com:81/habitat.pl [P]
On the back end I have MP2 and Apache2. How can I be sure keep alive
is off?
Is it done via the front or back?
Is this the wrong group f
On Wed, 2005-12-21 at 16:06 -0500, Jonathan Vanasco wrote:
> would it be possible having a non-apache proxy/vanilla server?
Possible to use keep-alive? No. The issue is the same, regardless of
what kind of server the front-end is. You do not want the backend
servers to wait around after finishi
would it be possible having a non-apache proxy/vanilla server?
i migrated my front-end server from apache2 to lighttpd.
i lost some features (proxying webdav isn't happy yet, and there's no
equivalent to mod_security yet) -- but i gained a ginormous increase
in speed and available resources
> "Fred" == Fred Moyer <[EMAIL PROTECTED]> writes:
Fred> Can you explain a bit more why using keep-alives to the backend is not
Fred> a good thing? I've always been under the impression from conference
Fred> lectures and literature that turning keep-alives on for the app server
Fred> is somet
Randal L. Schwartz wrote:
"Andreas" == Andreas J Koenig <[EMAIL PROTECTED]> writes:
Andreas> I'd also like to hear what people are doing when the apache model has
Andreas> scaling problems. We have one problematic project here: we're a
Andreas> gateway and must server a high number of very slow
> Okay, so you basically run two daemons -- mod_perl, and a separate
> multiplexing one -- to handle this? Did you investigate what would be
> involved in changing apache to support multiplexing as an MPM?
Yes -- we did look at that. The problem is that the MPM model assumes
that the handler runs
On Tue, 2005-12-20 at 09:00 -0800, Ken Simpson wrote:
> Instead of having one multiprocessing-oriented Apache mod_perl process
> per SMTP connection, we use a single event-driven process to handle
> all SMTP connections. To avoid blocking in this single process, we
> dispatch any CPU-intensive task
On Wed, 2005-12-21 at 08:09 +0100, Andreas J. Koenig wrote:
> I should not have mentioned that the customers are slow as well.
> Currently our main concern is that our processes have to wait for
> several data sources, then compute the answer and that our valuable
> memory is wasted during the wait
On 20 Dec 2005, at 12:00, Ken Simpson wrote:
Not sure what you mean by it not scaling - can you elaborate? Sure it
uses more ram than multiplexing, but even for a high traffic mail
server like apache.org's the mail-in-apache2 model works well
(apache.org uses Apache::Qpsmtpd for email).
I'm cur
> Not sure what you mean by it not scaling - can you elaborate? Sure it
> uses more ram than multiplexing, but even for a high traffic mail
> server like apache.org's the mail-in-apache2 model works well
> (apache.org uses Apache::Qpsmtpd for email).
>
> I'm curious as to how you've mixed thing
Hello,
On Monday 19 December 2005 04:18, JT Smith wrote:
> Apache is the ultimate event handler. It's listening for socket events. Why
> couldn't we change it just a bit to listen to timer events and thusly kick
> off an execution once per minute to check a cron tab. The reading of cron
> tabs is
You could look into the Twisted framework for python:
http://twistedmatrix.com/
It's a really solid networking framework, but its python based (not
perl).
On Dec 19, 2005, at 12:48 AM, JT Smith wrote:
Yup, I've actually already done it that way with both
Parallel::ForkManager in
Andreas J. Koenig wrote:
On 20 Dec 2005 16:21:42 -0800, merlyn@stonehenge.com (Randal L. Schwartz) said:
> Are you already using a reverse-proxy? Make sure the front lightweight
> servers *do* use cache and *don't* use keep-alive to the backend...
> your heavy backend will spit the en
> On 20 Dec 2005 16:21:42 -0800, merlyn@stonehenge.com (Randal L. Schwartz)
> said:
> Are you already using a reverse-proxy? Make sure the front lightweight
> servers *do* use cache and *don't* use keep-alive to the backend...
> your heavy backend will spit the entire response, and
ED]>;
Sent: Wednesday, December 21, 2005 6:25 AM
Subject: Re: go crazy with me
> >>>>> On Tue, 20 Dec 2005 09:40:43 -0500, Matt Sergeant
<[EMAIL PROTECTED]> said:
>
> > I'm curious as to how you've mixed things up though - if the details
> >
> "Andreas" == Andreas J Koenig <[EMAIL PROTECTED]> writes:
Andreas> I'd also like to hear what people are doing when the apache model has
Andreas> scaling problems. We have one problematic project here: we're a
Andreas> gateway and must server a high number of very slow customers to a high
An
> On Tue, 20 Dec 2005 09:40:43 -0500, Matt Sergeant <[EMAIL PROTECTED]>
> said:
> I'm curious as to how you've mixed things up though - if the details
> aren't private IP I'd love to know more.
Me too:-)
I'd also like to hear what people are doing when the apache model has
scaling p
On 19 Dec 2005, at 14:33, Stas Bekman wrote:
JT Smith wrote:
Yup, I've actually already done it that way with both
Parallel::ForkManager in one instance and Proc::Queue as an
alternative. I added in event handling with both Event and Event::Lib
as seperate trials. All those implementations we
Foo Ji-Haw wrote:
Just went to your company web site and read that you got the White Camel
award. Congrats, both on the award and your new career!
Thanks for the kind words, Foo!
We're talking to the Director of Development here guys... :)
Hehe, don't let titles mislead you :)
BTW, we are
T Smith" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, December 20, 2005 3:33 AM
Subject: Re: go crazy with me
> JT Smith wrote:
> > Yup, I've actually already done it that way with both
> > Parallel::ForkManager in one instance and Proc::Queue as an alternative.
> &
Hello,
On Monday 19 December 2005 04:18, JT Smith wrote:
> Apache is the ultimate event handler. It's listening for socket events. Why
> couldn't we change it just a bit to listen to timer events and thusly kick
> off an execution once per minute to check a cron tab. The reading of cron
> tabs is
On Mon, 19 Dec 2005, Perrin Harkins wrote:
On Mon, 2005-12-19 at 13:43 -0600, Chase Venters wrote:
What was happening? The application had been taking
messages into the queue, promising the call generator to handle them. Thus
the queue kept growing, and growing, and growing...
That is what a
On Mon, 2005-12-19 at 13:43 -0600, Chase Venters wrote:
> What was happening? The application had been taking
> messages into the queue, promising the call generator to handle them. Thus
> the queue kept growing, and growing, and growing...
That is what a queue is supposed to do when the demand
On Mon, 19 Dec 2005, Perrin Harkins wrote:
processes free for accepting jobs (as opposed to processing jobs). If
there are not, it adds the job to the queue and goes back to listening
for requests. If there are, it processes the job. This ensures that
processing jobs does not starve the abilit
JT Smith wrote:
Yup, I've actually already done it that way with both
Parallel::ForkManager in one instance and Proc::Queue as an alternative.
I added in event handling with both Event and Event::Lib as seperate
trials. All those implementations were relatively easy to do. But the
question bec
On Sun, 2005-12-18 at 23:48 -0600, JT Smith wrote:
> I added in event handling with both Event
> and Event::Lib as seperate trials.
I just used a short sleep with Time::HiRes between polling the database
for new jobs.
> If everything else is running in Apache, why start a
> seperate service to
Please, I specifically asked not to tell me how else to do it. I want to know how, if at
all, it's possible to do it under Apache/modperl. I know I can do it 1,000,000 other
ways that I'm totally not interested in. I just want everyone to focus on what's
possible with Apache/modperl, and nothing
Yup, I've actually already done it that way with both Parallel::ForkManager in one
instance and Proc::Queue as an alternative. I added in event handling with both Event
and Event::Lib as seperate trials. All those implementations were relatively easy to do.
But the question becomes, why? If ever
On Sun, 2005-12-18 at 21:18 -0600, JT Smith wrote:
> I want to turn it into a workflow system. If you think about it,
> workflow is nothing but a set of transactional tasks (nothing new) with two
> additional
> components (here's where it get's weird). The two additional components are
> cron
Forget for a second what Apache is. Think outside the box with me. Go a little
crazy.
Apache 2 (especially with mod_perl) opens up a whole new world of possibilities. There
are people turning apache into an FTP server, a chat server, a Mail server, a version
control system, etc. I want to turn
32 matches
Mail list logo
