Hello, I'm wrestling with an issue that has been unusually difficult for me to troubleshoot. 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" src="/auxiliary/js.php?file=global.js"></script> 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). http://tinypic.com/r/rh33mh/6 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 race-condition. I would very much appreciate insight from anybody who may know what's causing this behavior. Respectfully, -Ben --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|