Optimizing mod_fcgid

Hi,

I recently migrated from mod_fastcgi to mod_fcgid and experienced
enormous performance boost.

My current settings is as follows -

FcgidMaxProcesses 100
FcgidMaxProcessesPerClass 50
FcgidFixPathInfo 1
FcgidPassHeader HTTP_AUTHORIZATION
FcgidMaxRequestsPerProcess 10000
FcgidOutputBufferSize 1048576
FcgidProcessLifeTime 1800
FcgidMinProcessesPerClass 2

Main use is for PHP applications, but in future may add some languages.

Server config -

Fedora 12, 500 MB RAM, Pentium 2 Ghz

PHP applications are cached using Xcache, and will normally use PostgreSQL.

--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Optimizing mod_fcgid

On Sat, Mar 20, 2010 at 2:16 AM, Nilesh Govindarajan wrote:
> Hi,
>
> I recently migrated from mod_fastcgi to mod_fcgid and experienced enormous
> performance boost.
>
> My current settings is as follows -
>
> FcgidMaxProcesses 100
> FcgidMaxProcessesPerClass 50
> FcgidFixPathInfo 1
> FcgidPassHeader HTTP_AUTHORIZATION
> FcgidMaxRequestsPerProcess 10000

Since this is PHP, make sure you sync PHP's child exit strategy with
mod_fcgid's max-requests-per-process.

See "Special PHP considerations" at
http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html for discussion of
a couple of issues.

> FcgidOutputBufferSize 1048576
> FcgidProcessLifeTime 1800
> FcgidMinProcessesPerClass 2
>
> Main use is for PHP applications, but in future may add some languages.
>
> Server config -
>
> Fedora 12, 500 MB RAM, Pentium 2 Ghz
>
> PHP applications are cached using Xcache, and will normally use PostgreSQL.

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Optimizing mod_fcgid

On 03/23/2010 06:07 PM, Jeff Trawick wrote:
> On Sat, Mar 20, 2010 at 2:16 AM, Nilesh Govindarajan wrote:
>> Hi,
>>
>> I recently migrated from mod_fastcgi to mod_fcgid and experienced enormous
>> performance boost.
>>
>> My current settings is as follows -
>>
>> FcgidMaxProcesses 100
>> FcgidMaxProcessesPerClass 50
>> FcgidFixPathInfo 1
>> FcgidPassHeader HTTP_AUTHORIZATION
>> FcgidMaxRequestsPerProcess 10000
>
> Since this is PHP, make sure you sync PHP's child exit strategy with
> mod_fcgid's max-requests-per-process.
>
> See "Special PHP considerations" at
> http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html for discussion of
> a couple of issues.
>
>> FcgidOutputBufferSize 1048576
>> FcgidProcessLifeTime 1800
>> FcgidMinProcessesPerClass 2
>>
>> Main use is for PHP applications, but in future may add some languages.
>>
>> Server config -
>>
>> Fedora 12, 500 MB RAM, Pentium 2 Ghz
>>
>> PHP applications are cached using Xcache, and will normally use PostgreSQL.
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>

Yeah I've synced that by setting the relevant PHP_FCGI_* environment
variables.

But Xcache doesn't work with mod_fcgid. Any solutions for that ? Can I
use any alternatives to Xcache to cache the compiled code of the PHP
script ?

--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Optimizing mod_fcgid

On Tue, Mar 23, 2010 at 8:48 AM, Nilesh Govindarajan wro=
te:
> On 03/23/2010 06:07 PM, Jeff Trawick wrote:
>>
>> On Sat, Mar 20, 2010 at 2:16 AM, Nilesh Govindarajan
>> =A0wrote:
>>>
>>> Hi,
>>>
>>> I recently migrated from mod_fastcgi to mod_fcgid and experienced
>>> enormous
>>> performance boost.
>>>
>>> My current settings is as follows -
>>>
>>> FcgidMaxProcesses 100
>>> FcgidMaxProcessesPerClass 50
>>> FcgidFixPathInfo 1
>>> FcgidPassHeader HTTP_AUTHORIZATION
>>> FcgidMaxRequestsPerProcess 10000
>>
>> Since this is PHP, make sure you sync PHP's child exit strategy with
>> mod_fcgid's max-requests-per-process.
>>
>> See "Special PHP considerations" at
>> http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html for discussion of
>> a couple of issues.
>>
>>> FcgidOutputBufferSize 1048576
>>> FcgidProcessLifeTime 1800
>>> FcgidMinProcessesPerClass 2
>>>
>>> Main use is for PHP applications, but in future may add some languages.
>>>
>>> Server config -
>>>
>>> Fedora 12, 500 MB RAM, Pentium 2 Ghz
>>>
>>> PHP applications are cached using Xcache, and will normally use
>>> PostgreSQL.
>
> Yeah I've synced that by setting the relevant PHP_FCGI_* environment
> variables.
>
> But Xcache doesn't work with mod_fcgid. Any solutions for that ? Can I us=
e
> any alternatives to Xcache to cache the compiled code of the PHP script ?

Aren't APC and Xcache similar with respect to mod_fcgid, in that the
cache will be utilized for repeated execution by the same PHP process,
such that the cache is still useful as long as the PHP process spawned
by mod_fcgid remains active for as long as possible?

(mod_fcgid's mapping of requests to idle processes it has spawned
negates the use of a single such cache for multiple concurrent
requests.)

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Optimizing mod_fcgid

On 03/23/2010 07:20 PM, Jeff Trawick wrote:
> On Tue, Mar 23, 2010 at 8:48 AM, Nilesh Govindarajan wrote:
>> On 03/23/2010 06:07 PM, Jeff Trawick wrote:
>>>
>>> On Sat, Mar 20, 2010 at 2:16 AM, Nilesh Govindarajan
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I recently migrated from mod_fastcgi to mod_fcgid and experienced
>>>> enormous
>>>> performance boost.
>>>>
>>>> My current settings is as follows -
>>>>
>>>> FcgidMaxProcesses 100
>>>> FcgidMaxProcessesPerClass 50
>>>> FcgidFixPathInfo 1
>>>> FcgidPassHeader HTTP_AUTHORIZATION
>>>> FcgidMaxRequestsPerProcess 10000
>>>
>>> Since this is PHP, make sure you sync PHP's child exit strategy with
>>> mod_fcgid's max-requests-per-process.
>>>
>>> See "Special PHP considerations" at
>>> http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html for discussion of
>>> a couple of issues.
>>>
>>>> FcgidOutputBufferSize 1048576
>>>> FcgidProcessLifeTime 1800
>>>> FcgidMinProcessesPerClass 2
>>>>
>>>> Main use is for PHP applications, but in future may add some languages.
>>>>
>>>> Server config -
>>>>
>>>> Fedora 12, 500 MB RAM, Pentium 2 Ghz
>>>>
>>>> PHP applications are cached using Xcache, and will normally use
>>>> PostgreSQL.
>>
>> Yeah I've synced that by setting the relevant PHP_FCGI_* environment
>> variables.
>>
>> But Xcache doesn't work with mod_fcgid. Any solutions for that ? Can I use
>> any alternatives to Xcache to cache the compiled code of the PHP script ?
>
> Aren't APC and Xcache similar with respect to mod_fcgid, in that the
> cache will be utilized for repeated execution by the same PHP process,
> such that the cache is still useful as long as the PHP process spawned
> by mod_fcgid remains active for as long as possible?
>
> (mod_fcgid's mapping of requests to idle processes it has spawned
> negates the use of a single such cache for multiple concurrent
> requests.)
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>

Yeah true. I think I don't need it after you said this. :)

Is even memcached the same wrt mod_fcgid, apc, xcache ?

--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Optimizing mod_fcgid

On 03/23/2010 07:26 PM, Nilesh Govindarajan wrote:
> On 03/23/2010 07:20 PM, Jeff Trawick wrote:
>> On Tue, Mar 23, 2010 at 8:48 AM, Nilesh Govindarajan
>> wrote:
>>> On 03/23/2010 06:07 PM, Jeff Trawick wrote:
>>>>
>>>> On Sat, Mar 20, 2010 at 2:16 AM, Nilesh Govindarajan
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I recently migrated from mod_fastcgi to mod_fcgid and experienced
>>>>> enormous
>>>>> performance boost.
>>>>>
>>>>> My current settings is as follows -
>>>>>
>>>>> FcgidMaxProcesses 100
>>>>> FcgidMaxProcessesPerClass 50
>>>>> FcgidFixPathInfo 1
>>>>> FcgidPassHeader HTTP_AUTHORIZATION
>>>>> FcgidMaxRequestsPerProcess 10000
>>>>
>>>> Since this is PHP, make sure you sync PHP's child exit strategy with
>>>> mod_fcgid's max-requests-per-process.
>>>>
>>>> See "Special PHP considerations" at
>>>> http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html for discussion of
>>>> a couple of issues.
>>>>
>>>>> FcgidOutputBufferSize 1048576
>>>>> FcgidProcessLifeTime 1800
>>>>> FcgidMinProcessesPerClass 2
>>>>>
>>>>> Main use is for PHP applications, but in future may add some
>>>>> languages.
>>>>>
>>>>> Server config -
>>>>>
>>>>> Fedora 12, 500 MB RAM, Pentium 2 Ghz
>>>>>
>>>>> PHP applications are cached using Xcache, and will normally use
>>>>> PostgreSQL.
>>>
>>> Yeah I've synced that by setting the relevant PHP_FCGI_* environment
>>> variables.
>>>
>>> But Xcache doesn't work with mod_fcgid. Any solutions for that ? Can
>>> I use
>>> any alternatives to Xcache to cache the compiled code of the PHP
>>> script ?
>>
>> Aren't APC and Xcache similar with respect to mod_fcgid, in that the
>> cache will be utilized for repeated execution by the same PHP process,
>> such that the cache is still useful as long as the PHP process spawned
>> by mod_fcgid remains active for as long as possible?
>>
>> (mod_fcgid's mapping of requests to idle processes it has spawned
>> negates the use of a single such cache for multiple concurrent
>> requests.)
>>
>> ------------------------------------------------------------ ---------
>> The official User-To-User support forum of the Apache HTTP Server
>> Project.
>> See for more info.
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>
> Yeah true. I think I don't need it after you said this. :)
>
> Is even memcached the same wrt mod_fcgid, apc, xcache ?
>

I found that its not the same and it can't be used as a cache for
compiled scripts.

mod_fcgid really is infinite times better than mod_fastcgi.

--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Optimizing mod_fcgid

On Tue, Mar 23, 2010 at 10:02 AM, Nilesh Govindarajan wrote:
> On 03/23/2010 07:26 PM, Nilesh Govindarajan wrote:
>>
>> On 03/23/2010 07:20 PM, Jeff Trawick wrote:
>>>
>>> On Tue, Mar 23, 2010 at 8:48 AM, Nilesh Govindarajan
>>> wrote:
>>>>
>>>> On 03/23/2010 06:07 PM, Jeff Trawick wrote:
>>>>>
>>>>> On Sat, Mar 20, 2010 at 2:16 AM, Nilesh Govindarajan
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I recently migrated from mod_fastcgi to mod_fcgid and experienced
>>>>>> enormous
>>>>>> performance boost.
>>>>>>
>>>>>> My current settings is as follows -
>>>>>>
>>>>>> FcgidMaxProcesses 100
>>>>>> FcgidMaxProcessesPerClass 50
>>>>>> FcgidFixPathInfo 1
>>>>>> FcgidPassHeader HTTP_AUTHORIZATION
>>>>>> FcgidMaxRequestsPerProcess 10000
>>>>>
>>>>> Since this is PHP, make sure you sync PHP's child exit strategy with
>>>>> mod_fcgid's max-requests-per-process.
>>>>>
>>>>> See "Special PHP considerations" at
>>>>> http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html for discussion of
>>>>> a couple of issues.
>>>>>
>>>>>> FcgidOutputBufferSize 1048576
>>>>>> FcgidProcessLifeTime 1800
>>>>>> FcgidMinProcessesPerClass 2
>>>>>>
>>>>>> Main use is for PHP applications, but in future may add some
>>>>>> languages.
>>>>>>
>>>>>> Server config -
>>>>>>
>>>>>> Fedora 12, 500 MB RAM, Pentium 2 Ghz
>>>>>>
>>>>>> PHP applications are cached using Xcache, and will normally use
>>>>>> PostgreSQL.
>>>>
>>>> Yeah I've synced that by setting the relevant PHP_FCGI_* environment
>>>> variables.
>>>>
>>>> But Xcache doesn't work with mod_fcgid. Any solutions for that ? Can
>>>> I use
>>>> any alternatives to Xcache to cache the compiled code of the PHP
>>>> script ?
>>>
>>> Aren't APC and Xcache similar with respect to mod_fcgid, in that the
>>> cache will be utilized for repeated execution by the same PHP process,
>>> such that the cache is still useful as long as the PHP process spawned
>>> by mod_fcgid remains active for as long as possible?
>>>
>>> (mod_fcgid's mapping of requests to idle processes it has spawned
>>> negates the use of a single such cache for multiple concurrent
>>> requests.)
>>>
>>> ------------------------------------------------------------ ---------
>>> The official User-To-User support forum of the Apache HTTP Server
>>> Project.
>>> See for more info.
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>
>>
>> Yeah true. I think I don't need it after you said this. :)
>>
>> Is even memcached the same wrt mod_fcgid, apc, xcache ?
>>
>
> I found that its not the same and it can't be used as a cache for compiled
> scripts.
>
> mod_fcgid really is infinite times better than mod_fastcgi.

For PHP opcode caching, which relies on access to a shared memory
cache via the PHP FastCGI process management, mod_fcgid is at a big
disadvantage to mod_fcgid: mod_fastcgi can send multiple simultaneous
requests to those PHP-managed processes but mod_fcgid can't; thus, the
cache won't be as well utilized with mod_fcgid.

I have read numerous statements that mod_fcgid is faster than
mod_fastcgi, but I don't know precisely why (or when), or if each is
optimally configured when compared to the other.

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Optimizing mod_fcgid

On 03/23/2010 08:13 PM, Jeff Trawick wrote:
> On Tue, Mar 23, 2010 at 10:02 AM, Nilesh Govindarajan wrote:
>> On 03/23/2010 07:26 PM, Nilesh Govindarajan wrote:
>>>
>>> On 03/23/2010 07:20 PM, Jeff Trawick wrote:
>>>>
>>>> On Tue, Mar 23, 2010 at 8:48 AM, Nilesh Govindarajan
>>>> wrote:
>>>>>
>>>>> On 03/23/2010 06:07 PM, Jeff Trawick wrote:
>>>>>>
>>>>>> On Sat, Mar 20, 2010 at 2:16 AM, Nilesh Govindarajan
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I recently migrated from mod_fastcgi to mod_fcgid and experienced
>>>>>>> enormous
>>>>>>> performance boost.
>>>>>>>
>>>>>>> My current settings is as follows -
>>>>>>>
>>>>>>> FcgidMaxProcesses 100
>>>>>>> FcgidMaxProcessesPerClass 50
>>>>>>> FcgidFixPathInfo 1
>>>>>>> FcgidPassHeader HTTP_AUTHORIZATION
>>>>>>> FcgidMaxRequestsPerProcess 10000
>>>>>>
>>>>>> Since this is PHP, make sure you sync PHP's child exit strategy with
>>>>>> mod_fcgid's max-requests-per-process.
>>>>>>
>>>>>> See "Special PHP considerations" at
>>>>>> http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html for discussion of
>>>>>> a couple of issues.
>>>>>>
>>>>>>> FcgidOutputBufferSize 1048576
>>>>>>> FcgidProcessLifeTime 1800
>>>>>>> FcgidMinProcessesPerClass 2
>>>>>>>
>>>>>>> Main use is for PHP applications, but in future may add some
>>>>>>> languages.
>>>>>>>
>>>>>>> Server config -
>>>>>>>
>>>>>>> Fedora 12, 500 MB RAM, Pentium 2 Ghz
>>>>>>>
>>>>>>> PHP applications are cached using Xcache, and will normally use
>>>>>>> PostgreSQL.
>>>>>
>>>>> Yeah I've synced that by setting the relevant PHP_FCGI_* environment
>>>>> variables.
>>>>>
>>>>> But Xcache doesn't work with mod_fcgid. Any solutions for that ? Can
>>>>> I use
>>>>> any alternatives to Xcache to cache the compiled code of the PHP
>>>>> script ?
>>>>
>>>> Aren't APC and Xcache similar with respect to mod_fcgid, in that the
>>>> cache will be utilized for repeated execution by the same PHP process,
>>>> such that the cache is still useful as long as the PHP process spawned
>>>> by mod_fcgid remains active for as long as possible?
>>>>
>>>> (mod_fcgid's mapping of requests to idle processes it has spawned
>>>> negates the use of a single such cache for multiple concurrent
>>>> requests.)
>>>>
>>>> ------------------------------------------------------------ ---------
>>>> The official User-To-User support forum of the Apache HTTP Server
>>>> Project.
>>>> See for more info.
>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>
>>>
>>> Yeah true. I think I don't need it after you said this. :)
>>>
>>> Is even memcached the same wrt mod_fcgid, apc, xcache ?
>>>
>>
>> I found that its not the same and it can't be used as a cache for compiled
>> scripts.
>>
>> mod_fcgid really is infinite times better than mod_fastcgi.
>
> For PHP opcode caching, which relies on access to a shared memory
> cache via the PHP FastCGI process management, mod_fcgid is at a big
> disadvantage to mod_fcgid: mod_fastcgi can send multiple simultaneous
> requests to those PHP-managed processes but mod_fcgid can't; thus, the
> cache won't be as well utilized with mod_fcgid.
>
> I have read numerous statements that mod_fcgid is faster than
> mod_fastcgi, but I don't know precisely why (or when), or if each is
> optimally configured when compared to the other.
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>

I configured mod_fcgid with almost the same parameters as mod_fastcgi
and experienced a lot of performance boost.

--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Optimizing mod_fcgid

i too, would like to sing the praises of mod_fcgid to the community. my
background is web hosting with massive multi-user multi-site servers.

mod_fastcgi suffers from gross inadequacies in the model to which it was coded
for. such as: trying at all costs to keep starting a fastcgi target, even if the
target has no hope of starting without manual intervention (which for each
request in httpd, consumes a connection allocation!). this is not the end of the
world of a single user host but for a multiple virtual host server with several
end-users, this becomes a performance nightmare. there are also multiple points
where un-necessary stat() calls are made which can lead to huge performance
impacts on a nas based content server. mod_fastcgi also suffers from several
defects dring graceful restarts. if the number of fcgid- children exceeds the
point where killing those children takes longer than the parent server is
willing to wait for, you will end up with one or more orphans. oh, and those
orphans may still have their fcgid socket in use well after the new generation
of httpd children are live. it's a process management mess. also worth
mentioning, the development for mod_fastcgi stopped several years ago -- there's
no attempt to take advantage of the latest apr calls. the "latest" version of
mod_fastcgi (2.4.7) is somewhat obscurely available via
http://www.fastcgi.com/cvs/mod_fastcgi/. a positive side of mod_fastcgi is in
the FastCGIExternalServer directive. the downside to that directive is it
completely removes the ability to start/stop those external processes based on
load of the httpd server.

if you trace through the calls made, mod_fcgid is highly optimized when compared
to mod_fastcgi's spin up and request handling. mod_fcgid also has a much, much
better method of scoring spin up / spin down of child processes as well as the
logic involved to determine when a process should be ejected. you end up with a
much happier parent operating system if your fastcgi manager isn't thrashing the
system stopping and starting process.

using an uptime/performance measurement service (hi pingdom!), i charted a site
with mod_fastcgi compared to the same site's performance with mod_fcgid with
similar settings. the concept of an "exact comparison" is a bit awkward because
the two modules have completely different methods for scoring start/stops.

a simple php5 phpinfo() page:

mod_fastcgi:
Date Uptime (%) Downtime (h, m) Average response time
1 100% - 1348.25 ms
2 100% - 1367.06 ms
3 100% - 1467.31 ms
4 100% - 1467.31 ms
5 100% - 1486.37 ms
6 100% - 1344.41 ms
7 100% - 1385.31 ms
8 100% - 1443.91 ms
9 100% - 1348.83 ms

mod_fcgid:
Date Uptime (%) Downtime (h, m) Average response time
1 100% - 639.51 ms
2 100% - 559.67 ms
3 100% - 576.76 ms
4 100% - 563.08 ms
5 100% - 550.75 ms
6 100% - 511.2 ms
7 100% - 548.12 ms
8 100% - 565.57 ms
9 100% - 551.22 ms

yeah. i'll take the half second page loads over the 1.5 second page loads,
please.

i've modified my mod_fcgid to provide FcgidWrapper directive mapping based on
the handler type in addition to the file extension mapping, so handlers can
swapped (such as changing .php to be handled by php6 instead of php5) via
..htaccess and handled by a static set of interpreters.

what does this mean? instead of having to configure a wrapper such as:

FcgidWrapper /webserver/cgi-bin/php5-fcgi .php
FcgidWrapper /webserver/cgi-bin/php6-fcgi .php6

i can do this:

FcgidWrapper /webserver/cgi-bin/php5_3-fcgi .x-httpd-php5-3
FcgidWrapper /webserver/cgi-bin/php6-fcgi .x-httpd-php6

this then allows an end-user to quickly self-service a swap within an .htaccess,
without incurring a restart of apache:

AddHandler x-httpd-php5-3 .php
or
AddHandler x-httpd-php6 .php

and those specific .x-httpd defines are interpreted by mod_fcgid as handlers
that mod_fcgid accepts, instead of comparing the file extension during the "what
do i handle?" check:

in mod_fcgid.c:
static int fcgid_handler(request_rec * r)
{
....
if (fcgid_reverse_handler_check(r->handler) == 0) {
return DECLINED;
}
....


i still need to clean up my code and add a few more comments on what the code is
doing before i contribute it upstream.

anyway, mod_fcgid is totally awesome.

on the subject of xcache/apc -- it is moot to use those with mod_fcgid. you do
not want php to manage it's children (PHP_FCGI_CHILDREN=0). there have been issues
in the past with php's ability to handle termination of a main process's child
processes if the parent is killed before it's children using a SIGTERM/SIGKILL. you
want mod_fcgid to handle the number of php processes you need based on the
load/number of requests. it's what mod_fcgid does and it does it well. if you try
to use an opcode cacher with mod_fcgid, you end up with a cache per processes which
nullifies the point of the opcode cache.


-----
mike

On Tue, Mar 23, 2010 at 10:43 AM, Jeff Trawick said:
> On Tue, Mar 23, 2010 at 10:02 AM, Nilesh Govindarajan wrote:
> > On 03/23/2010 07:26 PM, Nilesh Govindarajan wrote:
> >>
> >> On 03/23/2010 07:20 PM, Jeff Trawick wrote:
> >>>
> >>> On Tue, Mar 23, 2010 at 8:48 AM, Nilesh Govindarajan
> >>> wrote:
> >>>>
> >>>> On 03/23/2010 06:07 PM, Jeff Trawick wrote:
> >>>>>
> >>>>> On Sat, Mar 20, 2010 at 2:16 AM, Nilesh Govindarajan
> >>>>> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I recently migrated from mod_fastcgi to mod_fcgid and experienced
> >>>>>> enormous
> >>>>>> performance boost.
> >>>>>>
> >>>>>> My current settings is as follows -
> >>>>>>
> >>>>>> FcgidMaxProcesses 100
> >>>>>> FcgidMaxProcessesPerClass 50
> >>>>>> FcgidFixPathInfo 1
> >>>>>> FcgidPassHeader HTTP_AUTHORIZATION
> >>>>>> FcgidMaxRequestsPerProcess 10000
> >>>>>
> >>>>> Since this is PHP, make sure you sync PHP's child exit strategy with
> >>>>> mod_fcgid's max-requests-per-process.
> >>>>>
> >>>>> See "Special PHP considerations" at
> >>>>> http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html for discussion of
> >>>>> a couple of issues.
> >>>>>
> >>>>>> FcgidOutputBufferSize 1048576
> >>>>>> FcgidProcessLifeTime 1800
> >>>>>> FcgidMinProcessesPerClass 2
> >>>>>>
> >>>>>> Main use is for PHP applications, but in future may add some
> >>>>>> languages.
> >>>>>>
> >>>>>> Server config -
> >>>>>>
> >>>>>> Fedora 12, 500 MB RAM, Pentium 2 Ghz
> >>>>>>
> >>>>>> PHP applications are cached using Xcache, and will normally use
> >>>>>> PostgreSQL.
> >>>>
> >>>> Yeah I've synced that by setting the relevant PHP_FCGI_* environment
> >>>> variables.
> >>>>
> >>>> But Xcache doesn't work with mod_fcgid. Any solutions for that ? Can
> >>>> I use
> >>>> any alternatives to Xcache to cache the compiled code of the PHP
> >>>> script ?
> >>>
> >>> Aren't APC and Xcache similar with respect to mod_fcgid, in that the
> >>> cache will be utilized for repeated execution by the same PHP process,
> >>> such that the cache is still useful as long as the PHP process spawned
> >>> by mod_fcgid remains active for as long as possible?
> >>>
> >>> (mod_fcgid's mapping of requests to idle processes it has spawned
> >>> negates the use of a single such cache for multiple concurrent
> >>> requests.)
> >>>
> >>> ------------------------------------------------------------ ---------
> >>> The official User-To-User support forum of the Apache HTTP Server
> >>> Project.
> >>> See for more info.
> >>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> >>> " from the digest: users-digest-unsubscribe@httpd.apache.org
> >>> For additional commands, e-mail: users-help@httpd.apache.org
> >>>
> >>
> >> Yeah true. I think I don't need it after you said this. :)
> >>
> >> Is even memcached the same wrt mod_fcgid, apc, xcache ?
> >>
> >
> > I found that its not the same and it can't be used as a cache for compiled
> > scripts.
> >
> > mod_fcgid really is infinite times better than mod_fastcgi.
>
> For PHP opcode caching, which relies on access to a shared memory
> cache via the PHP FastCGI process management, mod_fcgid is at a big
> disadvantage to mod_fcgid: mod_fastcgi can send multiple simultaneous
> requests to those PHP-managed processes but mod_fcgid can't; thus, the
> cache won't be as well utilized with mod_fcgid.
>
> I have read numerous statements that mod_fcgid is faster than
> mod_fastcgi, but I don't know precisely why (or when), or if each is
> optimally configured when compared to the other.
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org