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

go to bug id or search bugs for

Bug #19516 output buffer timing is strange
Submitted: 2002-09-20 03:20 UTC Modified: 2002-10-29 08:33 UTC
From: f dot labanvoye at cg70 dot fr Assigned:
Status: Not a bug Package: Output Control
PHP Version: 4.3.0pre2 OS: Windows 2000 server
Private report: No CVE-ID: None
View Developer Edit
 [2002-09-20 03:20 UTC] f dot labanvoye at cg70 dot fr 
on Windows 2000 SP2 FR, and php 4.2.3, the outbut buffer seems to not work correctly.

i make test to see the time taken to output data, and this time is not linear. 
explain, with output buffer = on in php.ini, all works fine. but with output_buffer=off ou output_buffer = 4096 or 8192 or more, the time for output data is very strange.

the script:
<?
include "exectimer.class.php";

$tip = new VWT_execTimeProfiler();

$suite = " vs print";

$max = 10000;

$tip->start();
$tip->watch("echo double");

for( $i=0;$i<$max;$i++) {
   print "echo $suite";
}

 echo "<hr>";
$tip->watch("echo en simple");
for( $j=0;$j<$max;$j++) {
   print 'echo '.$suite;
}


   $tip->stop();
$tip->show();
?>

the first for loop can take 100 ms to 800 ms when i change the size of output buffer.
if i increase the loop count, then the time for the second loop inrease, but the firt loop decrease.

When output_buffer is on, all works fine.

I don't see this bug on Linux.

PS: sorry for my bad english...

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-09-26 18:28 UTC] iliaa@php.net 
If you add \n to $suite variable does this change the timings in any signifcant way? Also, check to make sure you do not gzip compression enabled as well as try doing this test via a command line rather then a browser.
 [2002-10-01 02:44 UTC] f dot labanvoye at cg70 dot fr 
There is no difference with or without \n and in command line.
gzip is disabled for all test.

I think the problem is the rotation of the buffer. timing is good if the buffer size is greater or equal to the output size. 

all works fine on linux
 [2002-10-01 05:21 UTC] yohgaki@php.net 
It sounds like you are enabling zlib.output_compression. (If you are not using ob_gzhandler)

If yes, this is not a bug.
 [2002-10-14 08:10 UTC] f dot labanvoye at cg70 dot fr 
I rerun test with and without zlib_output_compression. there is no difference. 
i don't use ob_gzhandler.

with $max=1000 and output_buffer= 16384, the second loop is slower than the first. If i increase output_buffer to 32656 , the second loop take less time than the first ( it's the good result). The size odf output is 28ko.

I will run test with the php 4.3.0pre1 as soon as possible.
 [2002-10-24 15:34 UTC] iliaa@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip
 [2002-10-28 02:58 UTC] f dot labanvoye at cg70 dot fr 
I rerun the test with the 4.30pre1 version. I always have the same result on command line and with apache 1.3.27, but not with apache 2.0.43.

the problem is really visible with the output buffer to 16384 and $max = 1000 in the script.

I see that te first loop can take in buffer, so the timing for this loop is god, but the second loop can not tkae in buffer, so the timing is really bad.
 [2002-10-28 10:52 UTC] iliaa@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

pre2 is now out with several changes/fixes in output buffering code. Could you please verify if the problem is still there?
 [2002-10-29 04:37 UTC] f dot labanvoye at cg70 dot fr 
I have always the same result with the php4-latest ( 28 oct at 15:00 )
 [2002-10-29 05:11 UTC] sniper@php.net 
Some windows oddity. Works on Linux -> not bug.
 [2002-10-29 07:57 UTC] f dot labanvoye at cg70 dot fr 
If you don't want to fix bug on windows platforms, don't make a windows version of PHP.....


Thanks
 [2002-10-29 08:33 UTC] derick@php.net 
yeah... PHP would be much better of with all those Windows lusers anyway :-P
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Dec 20 22:00:01 2025 UTC