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 <trawick@xxxxxxxxx> said:
> On Tue, Mar 23, 2010 at 10:02 AM, Nilesh Govindarajan <lists@xxxxxxxxxx> 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<lists@xxxxxxxxxx>
> >>> wrote:
> >>>>
> >>>> On 03/23/2010 06:07 PM, Jeff Trawick wrote:
> >>>>>
> >>>>> On Sat, Mar 20, 2010 at 2:16 AM, Nilesh Govindarajan<lists@xxxxxxxxxx>
> >>>>> 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<URL:http://httpd.apache.org/userslist.html> for more info.
> >>> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> >>> " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
> >>> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
> >>>
> >>
> >> 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 <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|