Bug 145436 – PHP pages slow, HTTPD eating cpu

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 145436 - PHP pages slow, HTTPD eating cpu

Summary:	PHP pages slow, HTTPD eating cpu

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Enterprise Linux 3
Classification:	Red Hat
Component:	php (Show other bugs)
Sub Component:
Version:	3.0
Hardware:	i686 Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Joe Orton
QA Contact:	David Lawrence
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:	132991 146413
	Show dependency tree / graph

Reported:	2005-01-18 09:21 EST by Bernt Drange
Modified:	2007-11-30 17:07 EST (History)
CC List:	2 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2005-04-28 14:53:24 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2005:405	high	SHIPPED_LIVE	Moderate: PHP security update	2005-04-28 00:00:00 EDT

Groups: None (edit)

Description Bernt Drange 2005-01-18 09:21:29 EST

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
After upgrading from php-4.3.2-14.ent to php-4.3.2-19.ent our intranet
pages slowed down to a crawl. The load also increased.  

Reverting to the previous version fixed the problems. 

Version-Release number of selected component (if applicable):
php-4.3.2-19.ent

How reproducible:
Always

Steps to Reproduce:
Upgrade php to php-4.3.2-19.ent


Actual Results:  PHP pages slow down to a crawl. The load also increases.

Expected Results:  Normal performance, with closed security holes

Additional info:

ab -n 5 -c 1 http://our.server.com/ 

reported

Requests per second:    0.20 [#/sec] (mean)
Time per request:       5058.570 [ms] (mean)
Time per request:       5058.570 [ms] (mean, across all concurrent
requests)

After reverting to php-4.3.2-14.ent performance went back to what I
would consider more acceptable: 

Requests per second:    0.77 [#/sec] (mean)
Time per request:       1295.457 [ms] (mean)
Time per request:       1295.457 [ms] (mean, across all concurrent
requests)

I tested the newest version of php both with APC and ZendOptimizer
without any improvements. 

The server is running a content management system called mysource
classic. (http://www.squiz.net/).

Comment 1 Joe Orton 2005-01-18 11:26:42 EST

Thanks for the report.  There were some performance regressions in the
"unserializer" code introduced as a side-effect of the security fixes
in the recent PHP update.  Patches have been produced upstream which
correct the issue.

Experimental test packages are now available from the URL below which
 contain these patches.  These packages are unsupported and have not
gone through the Red Hat QA process.

http://people.redhat.com/jorton/Taroon-php/

Any feedback from testing these packages out is very welcome.

Comment 2 Bernt Drange 2005-01-19 10:44:16 EST

I just tested the packages. Seems like performance is good now! Great! 

ab -n 5 -c 1 outputs: 

Requests per second:    0.71 [#/sec] (mean)
Time per request:       1403.734 [ms] (mean)
Time per request:       1403.734 [ms] (mean, across all concurrent
requests)

I'm reverting to 4.3.2-14.ent since these experimental packes aren't
boss-proof. 

Cheers

Comment 3 Leonard den Ottolander 2005-03-12 18:41:13 EST

The performance regression is rather bad. Using phpGedView-3.00-1 that
heavily relies on unserialize(), rendering of index.php deteriorates
from a couple of secs to > 2 minutes (this is on a SuSE 9.0 box, both
plain as well as with a patch that updates var_unserialize.c to
4.3.10, but that shouldn't matter for the issue involved).

http://bugs.php.net/bug.php?id=31332 suggest this issue is fixed in
CVS for rev 1.47 and 1.48 of that particular file. However it seems
some other files are affected as well.

Comment 4 Leonard den Ottolander 2005-03-12 19:16:33 EST

A more appropriate CVS revision would be 1.18.4.15.

Comment 5 Leonard den Ottolander 2005-03-12 21:06:28 EST

Update of var_unserialize.c to CVS rev. 1.18.4.15 and php_var.h to CVS
rev. 1.21.4.5 indeed fixes the issue for me.

Note that that http://cvs.php.net is a bit sloppy about white space
(no space on empty lines for diffs and removed white space at end of
line) and these revisions contain some ^#line comments that should be
removed.

Comment 6 Josh Bressers 2005-04-28 14:53:24 EDT

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-405.html

Note You need to log in before you can comment on or make changes to this bug.