Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #6062 > unrolled thread

flush() with gzip

Back to article view | Back to comp.lang.php

Contents

  flush() with gzip Jason C <jwcarlton@gmail.com> - 2012-05-12 19:14 -0700
    Re: flush() with gzip "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-14 17:40 -0500
      Re: flush() with gzip Jason C <jwcarlton@gmail.com> - 2012-05-15 20:14 -0700
        Re: flush() with gzip Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-15 21:01 -0700
    Re: flush() with gzip Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-15 07:56 -0400
      Re: flush() with gzip Jason C <jwcarlton@gmail.com> - 2012-05-15 20:17 -0700

#6062 — flush() with gzip

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?

[toc] | [next] | [standalone]

#6064

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

[toc] | [prev] | [next] | [standalone]

#6072

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

[toc] | [prev] | [next] | [standalone]

#6074

On 5/15/12 8:14 PM, Jason C wrote:
> 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
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.

[toc] | [prev] | [next] | [standalone]

#6069

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.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6073

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web