Jump to content

Recommended Posts

Thanks for that last post MadTechie. I was suspecting this is how it works but just was not sure. So this is what I am going to try now.

[*]Increase PHP buffering. Set output_buffering = On

[*]Remove SendBufferSize sirective from Apache, hence leaving with system default which is 108544 (cat /proc/sys/net/core/wmem_default )

[*]Output string as whole. Do not split in chunks. I don't think Nagle Algorithm is a problem here

[*]In a shutdown function call ob_end_flush(). This step is probably optional since PHP flushes the buffer implicitly at the end of the execution.

 

I understand that this will not get rid of slow downs and probably will use more memory, but the plus here is that PHP process will finish and release any locks. As for memory usage it probably going to be less using PHP buffering than implementing a proxy/staging server that would accept all output and then spoon feed it to the client.

 

With the setup mentioned in the previous post I am still getting the long run times but now it is around ob_end_flush() as expected.

     $runtimes['before_flush'] = getExecuteTime();
     ob_end_flush();
     $runtimes['after_flush'] = getExecuteTime();

Result:

    [before_flush] => 0.9801812171936
    [after_flush] => 16.093120098114

 

 

Time:0.80782103538513 //Via Apache

Time:0.75758194923401 //Via PHP ONLY

BUT! the page took 44 Seconds to load

So the reason their was no timeout was because PHP had infact finished (BUT apache still had work todo).

--MadTechie :)

 

Are you sure that PHP had infact finished and quit? Wasn't it still running, waiting for apache to take care of the data in buffer? At least this is a case for me.

 

The workaround for me now is to explicitly release all locks in shutdown function before flushing. The better solution would be to setup a proxy or use lingerd.

 

Thanks for all the help.

 

 

PS. Its official ECHO is the slowest PHP statement! (not really  ;))

 

 

I did not try you scripts from CLI, but I tried them on my dev webserver. My results were inconsistent with yours:

 

For test1 I got:

Time:1.8898890018463 // Do not output to Apache

Time:10.101974010468 // Output through Apache

 

 

For test2 I got:

Time:1.9051520824432 // Do not output to Apache

Time:32.477254152298 // Output through Apache

 

Perhaps you have PHP deployed differently with Apache but on my installation whenever PHP starts to output data (echo or ob_end_flush()) to Apache it locks up until Apache is done. I have php installed as mod_php in Apache.

I believe I found a solution. PHP output buffers are stackable and it seems that the last buffer in a stack is bound to the PHP process and will halt the execution of the script when flushing. Any additional buffers do not seem to behave this way.

 

<?php
ini_set('output_buffering', 1);
//ob_start();
$str = ''; 
$c=0;
while ($c < 200000) {
      $c++;
      $str .= rand(1111111111, 9999999999) . "<br>\n";
}

$begin = microtime(true);
echo "<!--".$str."-->";
ob_end_flush();
echo 'Time: '.(microtime(true) - $begin)."\n<br/>";
?>

 

This code will output something like

Time: 5.2357218265533

but as soon as you uncomment ob_start() the output will be

Time: 0.037539958953857

 

The page is still going to take about 6 seconds to load but PHP will be done by then. This is what was important for me. I understand that there is no real way to speed up transfer of large files over slow networks but I want PHP to quit as soon as it is done generating content.

 

When ob_start() is not there the caching is still done but it is bound to PHP process. When ob_start() is called a new buffer gets opened that is independent of PHP process.

 

Hopefully this will help someone. Perhaps this was obvious to someone but I spent a week hunting this down.

 

Thanks for all the help.

 

 

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.