Return-Path: 
 <users-return-104482-apmail-httpd-users-archive=httpd.apache.org@httpd.apache.org>
X-Original-To: apmail-httpd-users-archive@www.apache.org
Delivered-To: apmail-httpd-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 038E6D2F0
	for <apmail-httpd-users-archive@www.apache.org>;
 Fri, 24 Aug 2012 18:43:42 +0000 (UTC)
Received: (qmail 98654 invoked by uid 500); 24 Aug 2012 18:43:38 -0000
Delivered-To: apmail-httpd-users-archive@httpd.apache.org
Received: (qmail 98630 invoked by uid 500); 24 Aug 2012 18:43:38 -0000
Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
list-help: <mailto:users-help@httpd.apache.org>
list-unsubscribe: <mailto:users-unsubscribe@httpd.apache.org>
List-Post: <mailto:users@httpd.apache.org>
List-Id: <users.httpd.apache.org>
Delivered-To: mailing list users@httpd.apache.org
Received: (qmail 98622 invoked by uid 99); 24 Aug 2012 18:43:38 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Aug 2012 18:43:38 +0000
X-ASF-Spam-Status: No, hits=0.1 required=5.0
	tests=FROM_12LTRDOM,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of ben@indietorrent.org designates
 205.186.134.222 as permitted sender)
Received: from [205.186.134.222] (HELO indietorrent.org) (205.186.134.222)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Aug 2012 18:43:31 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by indietorrent.org (Postfix) with ESMTP id 6475D6A30072
	for <users@httpd.apache.org>; Fri, 24 Aug 2012 11:43:09 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at indietorrent.org
Received: from indietorrent.org ([127.0.0.1])
	by localhost (indietorrent.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id bZoeoEWJZwyj for <users@httpd.apache.org>;
	Fri, 24 Aug 2012 11:43:08 -0700 (PDT)
Received: from [127.0.0.1] (cpe-142-105-206-5.maine.res.rr.com
 [142.105.206.5])
	(Authenticated sender: ben@indietorrent.org)
	by indietorrent.org (Postfix) with ESMTPSA id CB3DB6A30052
	for <users@httpd.apache.org>; Fri, 24 Aug 2012 11:43:08 -0700 (PDT)
Message-ID: <5037CB32.2050301@indietorrent.org>
Date: Fri, 24 Aug 2012 14:42:58 -0400
From: Ben Johnson <ben@indietorrent.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: users@httpd.apache.org
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [users@httpd] ModPHP performance is good,
 FastCGI is not: Resource limit? Lock?
 Race condition?

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@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org