Hello, I have posed this question to the Apache mailing list and nobody seems to have any insight ( http://mail-archives.apache.org/mod_mbox/httpd-users/201208.mbox/%[email protected]%3E ). Perhaps somebody here will be able to help. 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: Code: <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.2 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). [Please see attached file.] 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.1 - 0.2 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.
It's not really an answer, but have you tried it with nginx? Just to see if it's apache or fastcgi that's causing the problem.
Thanks for the post, Mark. I have not tried it with nginx, only because I have no experience with nginx, and I can't justify the time expenditure at the moment. That said, I'm rather curious how nginx would perform, comparatively. After a more thorough analysis of the scripts in question, under various PHP modes, I am beginning to think that the issue is simply "to be expected" when using PHP in CGI mode. While the CSS and JS wrapper scripts respond much slower under CGI than they do under ModPHP, the overall page-load times don't vary nearly as much, proportionately (due to asynchronicity). Ultimately, I concluded that the overhead associated with operating in CGI mode is responsible for the considerable response-time difference. Here's the short version of the page-load-time benchmarks that I performed in a relatively isolated environment: Code: Mod-PHP CGI suPHP Fast-CGI 1.3 1.56 1.41 1.87 1.26 1.36 1.72 1.82 1.17 1.72 1.41 1.91 1.31 1.39 1.37 1.67 1.28 1.29 1.83 1.79 1.31 1.48 1.25 1.85 1.29 1.36 1.36 1.83 1.35 1.42 1.23 1.77 1.29 1.55 1.66 1.76 1.31 1.37 1.68 1.69 Average 1.287 1.45 1.492 1.796 From this data, it's clear that ModPHP offers about 28% better performance than Fast-CGI for the type of application in question. Some day, I'll update this thread with nginx benchmarks, but for now, I'm forced to change the PHP mode to ModPHP.
It sure looks like it's indeed "all the same" .. though I can't believe this is a FastCGi issue (i've to see t for myself ) .. I've a nginx / fastcgi setup at work where I can test it for you tomorrow if you could supply me with some code to run or would some randomly generated content for the js/css files be enough?
