| Author |
 Topic  |
|
Kerry
Average Member
USA
553 Posts |
 Posted - 22 March 2001 : 16:39:33
|
I have an asp application that uses response.flush in numerous places throughout the script. I have an idea of what it does, but was wondering if anyone could offer some insight as to any advantages or disadvantages it's usage offers.
Thanks in advance,
Kerry
|
|
|
Da_Stimulator
DEV Team Forum Moderator
USA
3373 Posts |
Posted - 22 March 2001 : 16:41:03
|
I think it works something like response.clear - except maybe clears all session variables along with it?
----------------
Da_Stimulator
Need a Mod?
My Snitz Test Center
|
 |
|
|
gor
Retired Admin
Netherlands
5511 Posts |
Posted - 22 March 2001 : 16:54:28
|
Response.flush is not the same as Response.clear !
If you use:
Response.buffer = TRUE
The complete page is build on the server before being sent to the browser.
Advantages are that in total the page is being build faster, and you can still write things (i.e. cookies, but also Response.Redirect) in the header of the page even after you started outputting HTML code. You also can use Response.clear to cancel writes.
Response.flush sends all the data build sofar (including the header) to the browser. Disadvantage is that you can't write cookies anymore after the header has been sent, but an advantage is that the user can see the page being build.
Response.clear removes all the data that still is in the buffer, so that is either all the HTML code of the page sofar, or everything since the last Response.flush
If a page is completely build, an automatic Response.flush makes sure that content is sent to the browser.
Pierre |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 22 March 2001 : 16:56:35
|
Response.flush works with buffering
When you have buffering on, the server buffers the response (what it's going to send to the browser) and waits until the script has completely processed before sending the data. With response.flush, the browser will send out what it has built up in the buffer and send it out. This is useful when you have long pages as it allows something to be sent out the browser and they know that something is occurring. Response.Clear will erase anything in the buffer - and not send anything out.
|
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 22 March 2001 : 17:02:13
|
geez..should have waited with my response....gor's was detailed and similiar to the textbook description. 
|
|
|
|
gor
Retired Admin
Netherlands
5511 Posts |
Posted - 22 March 2001 : 17:21:37
|
Pierre |
|
|
|
Kerry
Average Member
USA
553 Posts |
Posted - 22 March 2001 : 17:36:06
|
Thanks to both for the info - I think I'm going to try and rework the code for speed a bit and do away with the flush just to see if the performance picks up.
-Kerry
|
|
|
|
gor
Retired Admin
Netherlands
5511 Posts |
Posted - 22 March 2001 : 17:43:25
|
Kerry,
Using response.buffer = true doesn't make the page load slower, it just might appear to load slower, it is something like the difference between interlaces gif-images and non-interlaced gif-images. The one appears to load faster, even if they are the exact same size.
Pierre |
|
|
|
Kerry
Average Member
USA
553 Posts |
Posted - 22 March 2001 : 17:58:21
|
Would that apply to flush as well? From the description it sounds as though it would require longer to build-send-build-send. Or am I misinterpreting?
-Kerry
|
|
|
|
Doug G
Support Moderator
USA
6493 Posts |
Posted - 22 March 2001 : 18:37:52
|
afaik, one of the main reasons to use response.flush is to make the pages appear to load faster by sending some stuff to the browser while your asp page is still chugging along.
======
Doug G
====== |
|
|
|
Kerry
Average Member
USA
553 Posts |
Posted - 23 March 2001 : 00:28:06
|
Gotcha 
Thanks for the help!
-Kerry
|
|
|
|
gor
Retired Admin
Netherlands
5511 Posts |
Posted - 23 March 2001 : 00:30:59
|
I think that is main reason.
Pierre |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 23 March 2001 : 07:35:43
|
Here is a good explanation...I could have rewritten it, but I'd rather copy and paste and give MSDN credit for the information.
25+ ASP Tips to Improve Performance and Style
Tip 14: Use Response Buffering
You can buffer a whole page worth of output by turning on "response buffering." This minimizes the amount of writes to the browser and thus improves overall performance. Each write has a lot of overhead (both in IIS and in the amount of data sent down the wire), so the fewer the writes there are, the better. TCP/IP works much more efficiently when it can send a few large blocks of data than when it has to send many small blocks because of its slow start and Nagling algorithms (used to minimize network congestion).
There are two ways of turning response buffering on. First, you can turn on response buffering for an entire application, using the Internet Services Manager. This is the recommended approach and response buffering is turned on by default for new ASP applications in IIS 4.0 and IIS 5.0. Second, on a page-by-page basis, you can enable response buffering by placing the following line of code near the top of the ASP page:
<% Response.Buffer = True %>
This line of code must be executed before any response data has been written to the browser (that is, before any HTML appears in the ASP script and before any Cookies have been set using the Response.Cookies collection). In general, it is best to turn response buffering on for an entire Application. This allows you to avoid the above line of code on every page.
Response.Flush
One common complaint about response buffering is that users perceive ASP pages as being less responsive (even though the overall response time is improved) because they have to wait for the entire page to be generated before they start to see anything. For long-running pages, you can turn response buffering off by setting Response.Buffer = False. However, a better strategy is to utilize the Response.Flush method. This method flushes all HTML that has been painted by ASP to the browser. For example, after painting 100 rows of a 1,000-row table, ASP can call Response.Flush to force the painted results to the browser; this allows the user to see the first 100 rows before the remaining rows are ready. This technique can give you the best of both worlds-response buffering combined with the gradual presentation of data to the browser.
(Note that in the above example of a 1,000-row table, many browsers won't start painting the table until they see the closing </table> tag. Check your targeted browsers for support. To get around this, try breaking the table into multiple tables with less rows, and call Response.Flush after each table. Newer versions of Internet Explorer will paint tables before they are fully downloaded, and will paint especially fast if you specify the table's column widths; this avoids forcing Internet Explorer to calculate the column widths by measuring the width of the contents of every cell.)
The other common complaint about response buffering is that it can use a lot of server memory when generating very large pages. Leaving aside the wisdom of generating large pages, this problem can also be addressed with judicious use of Response.Flush.
|
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 23 March 2001 : 07:38:34
|
Continued from the previous post, this also mentions why you would want to use buffering. This is from the same MSDN article referenced above.
Tip 15: Batch Inline Script and Response.Write Statements
The VBScript syntax <% = expression %> writes the value of "expression" to the ASP output stream. If response buffering is not turned on, then each of these statements results in writing data to the browser over the network in many small packets. This is slow. Also, interspersing small amounts of script and HTML causes switching between the script engine and HTML, reducing performance. Thus, use the following tip: Replace closely-bunched inline expressions with one call to Response.Write. For example, in the following sample, there is one write to the response stream per field per row, and many switches between VBScript and HTML per row:
<table>
<% For Each fld in rs.Fields %>
<th><% = fld.Name %></th>
<%
Next
While Not rs.EOF
%>
<tr>
<% For Each fld in rs.Fields %>
<td><% = fld.Value %></td>
<% Next
</tr>
<% rs.MoveNext
Wend %>
</table>
The more efficient code, below, has one write to the response stream per row. All of the code is contained within one VBScript block:
<table>
<%
For each fld in rs.Fields
Response.Write ("<th>" & fld.Name & "</th>" & vbCrLf)
Next
While Not rs.EOF
Response.Write ("<tr>")
For Each fld in rs.Fields %>
Response.Write("<td>" & fld.Value & "</td>" & vbCrLf)
Next
Response.Write "</tr>"
Wend
%>
</table>
This tip has a much bigger effect when response buffering is disabled. It's best to enable response buffering, and then see if batching Response.Write helps performance.
|
|
|
|
gor
Retired Admin
Netherlands
5511 Posts |
Posted - 23 March 2001 : 07:43:08
|
So this is what you mean by "the textbook description".
Pierre |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 23 March 2001 : 08:01:44
|
I apologize for the length of the above posts, but it should explain buffering best.
When I've used buffering, what I usually do is pick a couple of spots for a response.flush statement. For example if the top nav is a table by itself, I'll put a response.flush statement at the end of that block of code. That way the client gets the navigation immediately and can see that his/her request has been received and is being processed.
Also, when we are serving ads from another server using javascript, I'll usually try to put a response.flush statement nearby that chunk of code so that the browser gets it and can start to process that request simultaneously to the rest of the page. So hopefully, by the time my asp page is finished processing, the ads have also completely processed.
Maybe an analogy would work here.
Imagine a situation where you had two people reading a report and had to make a phone call to their manager to summarize what they had read. Person A had to make that phone call after every paragraph while Person B only had to make that phone call at the end of the report. While Person A would be the first to be heard from, Person A would only be calling with a little bit of data each time. Person B, not being distracted from having to make a phone call at each paragraph, would be the quickest in reading the entire report and would result in being the quickest to summarize the entire report.
If you haven't had buffering enabled before, the first time you turn it on and surf your site, you will notice this perception of a delay. With buffering off, the first bytes will be sent immediately and the browser will start processing/rendering what it receives. With buffering on, it's buffered or queued until the server is told to send it. But over the duration of the page being processed and if you could time the process down to when the last bytes were received, the buffering on method would probably be quickest.
|
|
|
|
Topic |
|
Topic Locked
