httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Johnson <>
Subject [users@httpd] ModPHP performance is good, FastCGI is not: Resource limit? Lock? Race condition?
Date Fri, 24 Aug 2012 18:42:58 GMT

I'm wrestling with an issue that has been unusually difficult for me to

I believe to have reduced the root cause to executing PHP sripts with
ModPHP vs. FastCGI.

Basically, I have an HTML document (generated via PHP, which isn't
necessarily relevant) that includes several external CSS and JavaScript
files. These files are included via standard HTML markup:

<link rel="stylesheet" type="text/css"
href="/auxiliary/css.php?file=global.css" />

<script type="text/javascript"

The only aspect of these URLs that is "unusual" is the dynamic file name
is that is appended in the query string. These PHP files (css.php and
js.php) are wrapper scripts that fetch template code (CSS and JS,
respectively), based on the "file" query string value and respond with
valid CSS and JS output.

The nature of the problem is that when several concurrent calls are made
to either of the wrapper scripts (when running in FastCGI mode), such as
when 4 or 5 CSS or JS files need to be embedded into the HTML page, the
responses take far too long to be received in the vast majority of cases.

I have profiled the scripts with xdebug and every request requires less
than 0.02 seconds of PHP processing-time. Yet, when I inspect the GET
request timeline, via Firebug's Net tab (in Firefox), the response times
for these requests are often 1.2 - 1.4 seconds.

The following image displays a side-by-side comparison of a typical
timeline when the PHP scripts (css.php and js.php) are executed in
ModPHP mode (shown on the left) vs. FastCGI mode (shown on the right).

Clearly, the CSS and JS file sizes have no bearing on how much time the
responses require. And given that the xdebug profiling data indicates
that PHP is spending only 0.01 - 0.02 seconds for each request, I am
lead to conclude that the problem is with Apache's configuration.

An interesting point of note is that the right-hand (FastCGI) side of
the image contains response times that alternate between 1.26s, 303ms,
and 1.32s. Why the alternation?

I seem to be hitting a CGI resource limit or some kind of locking or

I would very much appreciate insight from anybody who may know what's
causing this behavior.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message