0
votes

I just moved my website to GoDaddy hosting, and got everything working, but the PHP scripts aren't outputting the data immediately -- they're buffering until the script is finished running, and then rendering the whole page at once. And obviously, for long scripts, that's a problem. It didn't used to run that way with my old host, and GoDaddy support says they can't help with this. Here's what I've already tried (without any success)

  1. Disabled output compression (zlib, gzip)
  2. Set output_buffering = off in php.ini
  3. Set headers for Cache-Control "max-age=0, no-cache, no-store, must-revalidate", Pragma "no-cache", Expires "Wed, 10 May 1985 09:00:00 GMT", and unset the ETag header
  4. I also tried setting the buffering values in the script itself, using ini_set('output_buffering', 'off'), ini_set('zlib.output_compression', false), while (@ob_end_flush()), ini_set('implicit_flush', true), and ob_implicit_flush(true)
  5. And I tried running flush() and ob_flush() commands after every echo output
  6. Tried changing the PHP version from the default (5.4 native, which has APC enabled) to 5.4 non-native and 5.5

I also created a test script that simply loops for 5 iterations and outputs a line at every iteration, then waits a second before the next iteration. I did this to eliminate any other possible causes of problems. But no matter what I do, the script always waits until it completes before starting to render.

So, is there anything that I can do to make it work properly?

1
If disabling GZIP and using both ob_flush and flush don't work, there might be more going on. Perhaps a reverse proxy or something.Alexander O'Mara
^^ This seems likely. How long does it take to echo one line of text?Kevin_Kinsey
I;m not sure what you mean about "how long". If I just make a script that prints one line, is pretty much instant.user496854
Are you saying that GoDaddy is running a reverse proxy? And is there anything I can do about it if that's the case?user496854

1 Answers

0
votes

The first thing to note is that if you do succeed in disabling all buffering, you will make your shorter scripts much slower. Further, progressively flushing the HTML to the browser will not automatically result in the content being rendered at the browser; you may have successfully bypassed the the buffering serverside only to find that it's still being buffered in the browser. Try monitoring the traffic with a packet sniffer to find out if this is the case. It is possible to get the content rendered progressively with chunked encoding, but trivial.

As you seem to know, buffering will normally occur in the interface between PHP and the webserver, which can be flushed with:

while(ob_get_level()) {
   ob_end_flush(); 
}
flush();

Exactly when you flush the content has a big impact on performance. If there's a benefit to be had from early flushing then it's typically just after the head.../head section.

In order to compress the content effectively, most webserver will buffer the data. You don't say what webserver you are using, but if its Apache 2.x then you can reduce the size of this buffer (to match the size of the chunk before the flush) by way of the deflateBufferSize directive (more effective than disabling buffering altogether).

If this is Apache, do make sure that you have enabled keepalives.

If there are further proxies between you and the server,there's not much you can do with HTTP, but they will not impact HTTPS traffic.

Lastly, if you are using an anti virus product on your client, this may be the cause of a lot of problems - many interrupt the network connection between a browser and the network. IME they often leave a lot to be desired in the quality of how they do this.

At the end of the day, there are limits to what you do when you don't control the infrastructure. But there are other solutions than chunked encoding/progressive rendering.