flush() with gzip

Jason C

unread,

May 12, 2012, 10:14:12 PM5/12/12

to

I had read a couple of references (on Yahoo Developer, maybe?) to use flush() after the <body> tag to help speed up the delivery of a page. I'm not really having a speed issue at the moment, but figured that a gain of 500ms might help save a little server stress.

The thing I'm not clear on, though, is whether this works with Gzip compression, or is using Gzip taking precedent over flush() and making flush() irrelevant?

Peter H. Coffin

unread,

May 14, 2012, 6:40:58 PM5/14/12

to

On Sat, 12 May 2012 19:14:12 -0700 (PDT), Jason C wrote:

> I had read a couple of references (on Yahoo Developer, maybe?) to use
> flush() after the <body> tag to help speed up the delivery of a page.
> I'm not really having a speed issue at the moment, but figured that a
> gain of 500ms might help save a little server stress.

What problem are you trying to solve?

> The thing I'm not clear on, though, is whether this works with Gzip
> compression, or is using Gzip taking precedent over flush() and making
> flush() irrelevant?

gzip is certainly adding its own buffering to the mix, beyond what you
can control within PHP.

--
93. If I decide to hold a double execution of the hero and an underling
who failed or betrayed me, I will see to it that the hero is
scheduled to go first.
--Peter Anspach's list of things to do as an Evil Overlord

Jerry Stuckle

unread,

May 15, 2012, 7:56:20 AM5/15/12

to

On 5/12/2012 10:14 PM, Jason C wrote:
> I had read a couple of references (on Yahoo Developer, maybe?) to use flush() after the<body> tag to help speed up the delivery of a page. I'm not really having a speed issue at the moment, but figured that a gain of 500ms might help save a little server stress.
>
> The thing I'm not clear on, though, is whether this works with Gzip compression, or is using Gzip taking precedent over flush() and making flush() irrelevant?

Don't believe everything you read on the internet!

flush() will flush the PHP buffers to the server. But PHP can't control
what happens to the data after that. The server can buffer the data, it
can be cached by proxies between the server and the client, and the
client will buffer the data. The client may or may not display the data
before all of it arrives.

It's not like a C application where the application can flush data
directly to the screen.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================

Jason C

unread,

May 15, 2012, 11:14:53 PM5/15/12

to

On Monday, May 14, 2012 6:40:58 PM UTC-4, Peter H. Coffin wrote:
> > I had read a couple of references (on Yahoo Developer, maybe?) to use
> > flush() after the <body> tag to help speed up the delivery of a page.
> > I'm not really having a speed issue at the moment, but figured that a
> > gain of 500ms might help save a little server stress.
>
> What problem are you trying to solve?

I'm not trying to solve a problem, per se. I'm working on a new design and layout, and stumbled across the suggestion of using flush(). My sites are pretty demanding on the server, and I'm always working on away to speed things up, even if it's only by micros.

J

Jason C

unread,

May 15, 2012, 11:17:49 PM5/15/12

to

On Tuesday, May 15, 2012 7:56:20 AM UTC-4, Jerry Stuckle wrote:
> It's not like a C application where the application can flush data
> directly to the screen.

That's actually what I was hoping, that it would flush the data to the screen like C. If not, though, then I guess it's not quite what I'd hoped.

J

Daniel Pitts

unread,

May 16, 2012, 12:01:30 AM5/16/12

to

I don't think "flush" improves server performance. All the articles I've
seen that suggest flush talk about "first packet", getting things to the
client ASAP, so that the perceived performance is improved, especially
if the browser can start to fetch other resources defined in the <head>
section while the server continues to create the rest of the response.