php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23836 Performance of ob_start() is bad when lot of HTML data is printed afterwards
Submitted: 2003-05-27 12:02 UTC Modified: 2003-06-29 20:13 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: webmaster at maczsoftware dot com Assigned:
Status: Not a bug Package: Output Control
PHP Version: 4.3.2RC4 OS: RedHat Linux 8.0
Private report: No CVE-ID: None
 [2003-05-27 12:02 UTC] webmaster at maczsoftware dot com
I'm having some pretty weird issues with ob_start() function. I have a merely complex script, which parses XML file (its functionality is located in own class, which is included from another php file). Because this script can output pretty much data, I'm buffering the output and then send it to browser gzipped.

However, the execution time of my script is 23 seconds with large XML file, so I started to investigate possibilities of optimization. I thought - of course - that XML parsing was taking too long, but when I started to count seconds with getmicrotime() function, I found out that ob_start("ob_gzhandler") was taking 14 seconds of that 23! 
So I suppose this could be a bug in the PHP. I'm not saying that the script is too slow, 23 secs can be completely possible, but that calling getmicrotime() right before and right after ob_start() and getting 14 secs can't be right.

All data is printed after ob_start() call, and at the end of the script ob_end_flush() is called. I have also tried using non-gzipped output, with pretty same processing time. The code which relates to this problem is below:

Code:

$before = getmicrotime();
ob_start("ob_gzhandler");
$after = getmicrotime();

// Here comes some XML parsing and printing some large text data
// ...

print "Time usage for ob_start: " . ($after - $before) . " seconds\n";
ob_end_flush();

// This is standard getmicrotime from php.net
function getmicrotime()
{
        list($usec, $sec) = explode(" ",microtime());
        return ((float)$usec + (float)$sec);
}



---
PHP INFO:
PHP 4.3.2RC4 (cli) (built: May 22 2003 16:30:41)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies

Configure line:
./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --with-gd --with-zlib-dir=/usr/local --enable-memory-limit


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-27 17:26 UTC] sniper@php.net
Please provide a complete but short and self-contained example script which we can try ourselves.

 [2003-05-28 00:56 UTC] webmaster at maczsoftware dot com
Since this issue needs an external XML file (to be 
parsed) to produce such a problem, I've included it 
also. Script and XML file are packed in one package 
(113 KB): http://www.maczsoftware.com/files/misc/
ob_start_performance.tar.gz

To reproduce the issue just run the script (tunes.php) 
without any modifications. ob_start() takes several 
seconds to run. The call to ob_start is located at 
tunes.php at line 32. This script tells itself about 
time consumption at the end of the produced HTML data.
 [2003-06-29 20:13 UTC] iliaa@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Using gzhandler caused the entire output of your page to be buffered in memory before being sent to the user. If you are outputing large amount of text this process would involve quite a few memory reallocation calls not to mention the compression overhead. While it may be unnoticeable on small pages that do no generate a lot of output on large pages you'll definately feel the performance loss.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat May 18 12:01:32 2024 UTC