tackling this another way.
how hard would it be to use something like mod_fastcgi of instead of
the standard CGI interface?
On 21/06/2006, at 8:00 AM, Paul Querna wrote:
Mendonce, Kiran (STSD) wrote:
We tried using mod_cgi with worker. And its very slow. So that's
not an
option we
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 21, 2006 4:54 AM
To: dev@httpd.apache.org
Subject: Re: Question on multi-process CGID
tackling this another way.
how hard would it be to use something like mod_fastcgi of instead of the
standard CGI interface?
On 21/06/2006, at 8:00 AM, Paul Querna
It depends on where the real bottleneck is.
Most of the time, if you are unable to cope with the volume of incoming
CGI requests, its because your CGIs themselves are slow to start.
For example, if your CGIs are coded in Perl, just starting them can
take a long time, which is independent of
Mendonce, Kiran (STSD) wrote:
It depends on where the real bottleneck is.
Most of the time, if you are unable to cope with the volume of incoming
CGI requests, its because your CGIs themselves are slow to start.
For example, if your CGIs are coded in Perl, just starting them can
take a
is it that the benchmarking numbers
fall short ?
Regards,
Kiran
-Original Message-
From: Paul Querna [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 1:44 PM
To: dev@httpd.apache.org
Subject: Re: Question on multi-process CGID
Mendonce, Kiran (STSD) wrote:
It depends on where
2:18 PM
To: dev@httpd.apache.org
Subject: Re: Question on multi-process CGID
Mendonce, Kiran (STSD) wrote:
I am looking into the probable bottlenecks.
Agreed that the worker MPM has its advantages. But for a customer who
is being asked to move to Apache 2.0, we are falling short
Mendonce, Kiran (STSD) wrote:
We tried using mod_cgi with worker. And its very slow. So that's not an
option we have. Currently we have only worker MPM supported on HP-UX
which is why I tried the multiple cgid approach.
Ah. Now it makes sense. My experiences with this have only been on
Mendonce, Kiran (STSD) wrote:
Hi,
We had a scenario where the worker MPM was not performing as expected.
The bottleneck was identified as a single CGI daemon not being able to
cope with the volume of CGI requests coming in. So I made some changes
to convert the single process CGI daemon to