|
Buffer That Output by Charles Carroll
In my recent advanced class we recently confirmed
my fanatical belief in
<%response.buffer=true%>
and cautious <%response.flush%>
something I hammer into every Intro student I teach every day of my class.
We did dozens of millisecond speed tests ala:
http://www.learnasp.com/freebook/asp/speedtimer.aspx
reading 500 database records. Every change (Getrows or Getstring, One gulp, or
50 rows at a time, named or numbered fields) was timed. Many of these
suboptimizations reduced a 4 second task to 2 seconds. But the buffer trick got
it down to 3/10 of a second!!!! Why?????
Lets tell the waiter analogy....
A waiter comes to your table in a busy
restaurant. There are 5 at your table. He asks what drink person #1 wants and
THEN hops to a different table and lets them order 1 drink and then hops to a
different table and asks 1 person what their main course is and then a different
table to ask what dessert another person wants. Then he comes back to your table
and asks person #2 what drink they want. Then hops all over again.
This story is your webserver with <%response.buffer=false%>
(the default in IIS4 and IIS3). Though it might seem slower to the adjacent
table for him to finish your order, overall it is faster for him to do one at a
time.
Chaos, not Order
Also if a script is <%response.buffer=false%>
the number of gulps it takes to move 10k is determined by the browser and server
in a chaotic very hard to determine fashion...
5 gulps of 2k
10 gulps of 1k
3 gulps of 3k + 1k gulp
It is not efficient.
But if a script is <%response.buffer=true%>
==> 1 gulp of 10k <==
If 300 people ask for that script, 300 transfers,
not 301...3000 transfers depending on many factors.
BUT, lets say you have a page like this:
<%response.buffer=true%>
... 1k of HTML ...
... 20k graphic ...
... 45k background sound ...
... 4k of HTML ...
Some facts:
- The page will serve quicker if many people hit the site. Go back to waiter
analogy. 69k in 1 gulp x a couple hundred users is much easier than a couple
hundred fragmented gulps.
Now the sane man compromises:
<%response.buffer=true%>
... 1k of HTML and/or ASP ...
<%response.flush%>
... 20k graphic ...
<response.flush%>
... 45k background sound ...
... 4k of HTML and/or ASP ...
Now:
- The user sees some output at the browser for
every upon each flush.
- The whole page serves in 3 controlled
gulps NO more chaos.
- Control. Not anarchy.
A Simple Change to Speed Up Your Server
I once had an overloaded 100% CPU server. I
changed registry so all pages were buffer=true. The server then oscillated
instead of staying pegged at 100%. Proof incarnate. Users were much happier. No
money spent no code changes.
When Good Pets Go Bad, err I mean...
When response.flush goes bad
Two of my students would like to add to this
advice.
Rob Reno from Florida found too many
response.flushes slows down his page and has diminishing returns. Code like
this
<%response.buffer=true%>
... 1k of HTML and/or ASP ...
<%do until rstemp.eof
... process data ...
rstemp.movenext
response.flush
LOOP
will show output often BUT if there is 1000
records that is 1000 response.flushes.
Change the above code to:
<%response.buffer=true%>
... 1k of HTML and/or ASP ...
<%do until rstemp.eof
counter=counter+1
... process data ...
rstemp.movenext
If counter MOD 200=0 THEN
response.flush
END IF
LOOP
will now flush at record 200, 400,600,800,1000 --
5 flushes total.
Doug Cannon from Utah writes....
The one thing that you may not have tested for
this article is how response.flush behaves on a very slow internet connection
(28.8 bps, for example). Our audience on www.myfamily.com
still uses a lot of 28.8 and 33.6 modems to attach to our site. We were noticing
some VERY slow speeds on many of our pages. We religiously used RESPONSE.BUFFER
= TRUE on every page, and two RESPONSE.FLUSH commands per page. We found out,
and Microsoft finally admitted, that the response.flush waits for the client
browser to acknowledge the flush before continuing to process the ASP code. One
a very fast internet connection, you don't notice the problem, but a slower
modem takes longer to perform that task, and therefore a flush can be bad.
We still use response.buffer=true, of course.
However, we have removed all response.flush commands from the site, and we saw
an instant and dramatic speed improvement.
My comment: I have used several
response.flushes on 28.8 connections with success and speed BUT my servers
weren't as busy as www.myfamily.com . Due
to the round-robin nature of script execution (see /advice/roundrobin.asp)
their servers may take longer for a response.flush than lightly loaded servers!
|