php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #51466 zlib.output_compression gets disabled on some processes
Submitted: 2010-04-02 22:09 UTC Modified: 2012-03-16 09:28 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: radek at pinkbike dot com Assigned: mike (profile)
Status: No Feedback Package: Output Control
PHP Version: 5.2.13 OS: Centos 5.3 x86_64
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: radek at pinkbike dot com
New email:
PHP Version: OS:

 

 [2010-04-02 22:09 UTC] radek at pinkbike dot com 
Description:
------------
PHP 5.2.13 
Linux r56 2.6.18-164.11.1.el5 #1 SMP Wed Jan 20 07:32:21 EST 2010 x86_64 x86_64 
x86_64 GNU/LinuxApache/2.2.3 (CentOS) mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5


On a fairly busy server, (50 php req/s) we see that some processes stop 
compressing page output.  I have narrowed it down to where a process pid which 
transitions to this state, remains in this state until recycled/restarted 
(MaxRequestsPerChild reached).
In this state, where gzip is not working, output headers do not contain Content 
encodign gzip, so the output is fine.  It's just not using compression.

So when all processes are restarted, page compression works correctly for some 
indeterminate time, after which, some processes transition to a state where they 
do not compress the output. Once in this state a process ALWAYS ignores the 
compression until recycled.

Some additional info:
We only run a max limit of 100 processes, and typically active processes are 
about 20 or so.
I have decreased MaxRequestsPerChild to about 40,000 which recycles processes 
every 2 hours or so, and we still see about 50% of our pages delivered without 
compression.



Expected result:
----------------
The problem happens with zlib.output_compression on.  If I use output_handler = 
ob_gzhandler, compression never degrades, and it works as expected.


Actual result:
--------------
I am not sure what the trigger is but would like to help solve this issue.  If 
someone can give me some insight into this I can debug further.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-09-19 14:42 UTC] mike@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: mike
 [2011-09-19 14:42 UTC] mike@php.net 
Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/
 [2012-03-16 09:28 UTC] mike@php.net
-Status: Feedback +Status: No Feedback
 [2012-03-16 09:28 UTC] mike@php.net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 19:01:28 2024 UTC