Setting Response.Buffer = True can be an easy way to increase the speed of your
site. Buffering prevents IIS from sending any response to the browser until
the server is completely done processing your ASP script. While this might
seem like it would take more time and resources to store this information
until you send it, it actually takes less. This is because of the inherent
time savings of being able to do things in batches (resulting in fewer context
switches) and because the server is then able to transfer the resulting HTML
in a few large blocks instead of lots of little ones.
This is the default setting in new installations of IIS5, but is not in IIS4
or in IIS5 if it was installed as an upgrade of IIS4. To check the current
setting you can use this ASP code snippet:
You can also change the value on a page by page basis by setting it to a
boolean value at the top of your ASP page:
Response.Buffer = True
But perhaps the best way to control buffering is via Internet Service Manager.
Bring up the properties for the web site whose buffering setting you want to
change. In the "Application Setting" section, click on the
"Configuration" button. Click on the "App Options"
tab in the resulting dialog box. There you'll find a checkbox which will
indicate the current buffering setting and allow you to change it.
Depending on your site, buffering may make your site appear to respond more
slowly. This is caused by the slower initial response of the server when
returning the first parts of the HTML since it now has to wait until it has
it all to return even the initial response. While it really does finish
faster, on the web appearence is often just as (if not more) important than
actual speed. To alleviate this problem and still gain the benefits of
buffering, you can selectively send back chunks of data as you see fit by
using Response.Flush. How much it will help and how frequently you should
use it on the page vary widely from site to site so you should experiment
some to find the settings that work best for you.
One of our readers wrote in and wanted to share a comment about how browsers
render long tables.
A comment to add:
If the output is long (ie. data from 500 rows in a database) and is
incorprated in a table structure in the HTML output then using
Response.Flush command will most likely not help.
The client browser typically needs to see the end of the table before
it can start to format and display the table (or the data therein).
I hope this helps!
Thanks for the tip Kim. One way to help in situations such as this
is to break the large table into a number of smaller tables. For
example, instead of showing 500 rows of data in one long table, you might try
closing the table every 100 rows, issuing the Response.Flush command,
and then starting a new table for the next group of 100 rows. This way
the browser can render the table containing the first 100 rows of data without
waiting until it receives the entire 500 rows of data.
As I said before... a lot of these decisions will be based on your specific
situation. While no single solution will work for everyone, with
some basic knowledge of how buffering works and a little bit
of testing you should be able to find a solution that works well for you.