Hi All
Could somebody outline what are the pluses and minuses of using
Response.Buffer = True at the top of my ASP pages.
I was told by a poster a long time ago that using this command if you can
get away with it gives a better output (?!?!?), but I never found out what
he meant by getting away with it or what he meant by a better output.
Thanks
Laphan
Generally, you will get better performance.
IIS will hang onto the entire response before placing it onto the network.
This leads to nice, full, packets leaving the server, and a minimum of
switches between ASP processing something, and Windows placing packets onto
the wire.
If you have buffering *off*, then IIS will continually be placing dribs and
drabs of output onto the wire. If you want to test it, try doing this:
<%
For i = 1 to 100000
Response.Write("Hello" & "
")
Next
%>
Do the above with buffering on, and with buffering off. One should take a
significantly shorter time than the other (obviously you should do this
across the network)
Cheers
Ken
"Laphan"
news:eyVrFQ%23qEHA.3416@TK2MSFTNGP15.phx.gbl...
> Hi All
>
> Could somebody outline what are the pluses and minuses of using
> Response.Buffer = True at the top of my ASP pages.
>
> I was told by a poster a long time ago that using this command if you can
> get away with it gives a better output (?!?!?), but I never found out what
> he meant by getting away with it or what he meant by a better output.
>
> Thanks
>
> Laphan
>
>
Laphan wrote:
> Hi All
> Could somebody outline what are the pluses and minuses of using
> Response.Buffer = True at the top of my ASP pages.
> I was told by a poster a long time ago that using this command if you can
> get away with it gives a better output (?!?!?), but I never found out what
> he meant by getting away with it or what he meant by a better output.
> Thanks
> Laphan
Ken Schaefer's analysis is spot on.
A little IIS history:
IIRC IIS4 and IIS3 had buffering *disabled* (FALSE) by default. But
buffering is enabled (TRUE) by default for IIS5 and later versions.
That may explain why the poster you referenced suggesting setting
Response.Buffer = TRUE.
So while it is no longer _usually_ necessary, if there is a need to
enable buffering (e.g., the code includes calls to Response.Clear), then
you should keep the statement in your code.
Good Luck,
Michael D. Kersey
Hi Guys
Thanks for the replies.
The reason I wanted to know any negative sides to this is that the site that
I have currently done is experiencing a lot of server timeouts even though
the script execution should be an enormous burden.
I used .GetRows on all of the DB retrieval work thinking that this would
give better speed (I use about 3 or 4 DB query calls per page whilst still
using the same 1 connection), but I have a feeling that because I am using
Response.Buffer = True My ISP's IIS is classing all of the calls as one and
generating a timeout because of the time it is taking to do everything
before it returns it all. Could this be the case?
I don't want to do the classic answer of increasing the timeout delay, as I
think I would be disguising a problem.
Rgds
Robbie
"Michael D. Kersey"
news:OpIWpIDrEHA.3848@TK2MSFTNGP14.phx.gbl...
Laphan wrote:
> Hi All
> Could somebody outline what are the pluses and minuses of using
> Response.Buffer = True at the top of my ASP pages.
> I was told by a poster a long time ago that using this command if you can
> get away with it gives a better output (?!?!?), but I never found out what
> he meant by getting away with it or what he meant by a better output.
> Thanks
> Laphan
Ken Schaefer's analysis is spot on.
A little IIS history:
IIRC IIS4 and IIS3 had buffering *disabled* (FALSE) by default. But
buffering is enabled (TRUE) by default for IIS5 and later versions.
That may explain why the poster you referenced suggesting setting
Response.Buffer = TRUE.
So while it is no longer _usually_ necessary, if there is a need to
enable buffering (e.g., the code includes calls to Response.Clear), then
you should keep the statement in your code.
Good Luck,
Michael D. Kersey
We would need to see the script - it would probably have more impact on the
speed / timeout issue than setting the buffer
"Astra"
news:e16IVqErEHA.1204@TK2MSFTNGP12.phx.gbl...
> Hi Guys
>
> Thanks for the replies.
>
> The reason I wanted to know any negative sides to this is that the site
that
> I have currently done is experiencing a lot of server timeouts even though
> the script execution should be an enormous burden.
>
> I used .GetRows on all of the DB retrieval work thinking that this would
> give better speed (I use about 3 or 4 DB query calls per page whilst still
> using the same 1 connection), but I have a feeling that because I am using
> Response.Buffer = True My ISP's IIS is classing all of the calls as one
and
> generating a timeout because of the time it is taking to do everything
> before it returns it all. Could this be the case?
>
> I don't want to do the classic answer of increasing the timeout delay, as
I
> think I would be disguising a problem.
>
> Rgds
>
> Robbie
>
>
> "Michael D. Kersey"
> news:OpIWpIDrEHA.3848@TK2MSFTNGP14.phx.gbl...
> Laphan wrote:
> > Hi All
> > Could somebody outline what are the pluses and minuses of using
> > Response.Buffer = True at the top of my ASP pages.
> > I was told by a poster a long time ago that using this command if you
can
> > get away with it gives a better output (?!?!?), but I never found out
what
> > he meant by getting away with it or what he meant by a better output.
> > Thanks
> > Laphan
>
> Ken Schaefer's analysis is spot on.
>
> A little IIS history:
> IIRC IIS4 and IIS3 had buffering *disabled* (FALSE) by default. But
> buffering is enabled (TRUE) by default for IIS5 and later versions.
> That may explain why the poster you referenced suggesting setting
> Response.Buffer = TRUE.
>
> So while it is no longer _usually_ necessary, if there is a need to
> enable buffering (e.g., the code includes calls to Response.Clear), then
> you should keep the statement in your code.
>
> Good Luck,
> Michael D. Kersey
>
>
>
>
>
Buffering should have no effect on a server-side script timeout...
Cheers
Ken
"Astra"
news:e16IVqErEHA.1204@TK2MSFTNGP12.phx.gbl...
> Hi Guys
>
> Thanks for the replies.
>
> The reason I wanted to know any negative sides to this is that the site
> that
> I have currently done is experiencing a lot of server timeouts even though
> the script execution should be an enormous burden.
>
> I used .GetRows on all of the DB retrieval work thinking that this would
> give better speed (I use about 3 or 4 DB query calls per page whilst still
> using the same 1 connection), but I have a feeling that because I am using
> Response.Buffer = True My ISP's IIS is classing all of the calls as one
> and
> generating a timeout because of the time it is taking to do everything
> before it returns it all. Could this be the case?
>
> I don't want to do the classic answer of increasing the timeout delay, as
> I
> think I would be disguising a problem.
>
> Rgds
>
> Robbie
>
>
> "Michael D. Kersey"
> news:OpIWpIDrEHA.3848@TK2MSFTNGP14.phx.gbl...
> Laphan wrote:
>> Hi All
>> Could somebody outline what are the pluses and minuses of using
>> Response.Buffer = True at the top of my ASP pages.
>> I was told by a poster a long time ago that using this command if you can
>> get away with it gives a better output (?!?!?), but I never found out
>> what
>> he meant by getting away with it or what he meant by a better output.
>> Thanks
>> Laphan
>
> Ken Schaefer's analysis is spot on.
>
> A little IIS history:
> IIRC IIS4 and IIS3 had buffering *disabled* (FALSE) by default. But
> buffering is enabled (TRUE) by default for IIS5 and later versions.
> That may explain why the poster you referenced suggesting setting
> Response.Buffer = TRUE.
>
> So while it is no longer _usually_ necessary, if there is a need to
> enable buffering (e.g., the code includes calls to Response.Clear), then
> you should keep the statement in your code.
>
> Good Luck,
> Michael D. Kersey
>
>
>
>
>
Hi Guys
I will put together a script sample so you can see it, but it seems really
weird that the exact same page scripts run fine one minute and are then
timing out the next.
I know the first thing you are going to say is that I should be using PHP
rather than my chosen combo of ASP (on a W2003 Server) > MyODBC (on the same
W2003 Server) > MySQL 4 db (on a Linux server - I think), but this seems to
work really well when it does.
Do you know of any issues with the above combo?
Rgds
Robbie
"Ken Schaefer"
news:uPE8XwFrEHA.4008@TK2MSFTNGP14.phx.gbl...
Buffering should have no effect on a server-side script timeout...
Cheers
Ken
"Astra"
news:e16IVqErEHA.1204@TK2MSFTNGP12.phx.gbl...
> Hi Guys
>
> Thanks for the replies.
>
> The reason I wanted to know any negative sides to this is that the site
> that
> I have currently done is experiencing a lot of server timeouts even though
> the script execution should be an enormous burden.
>
> I used .GetRows on all of the DB retrieval work thinking that this would
> give better speed (I use about 3 or 4 DB query calls per page whilst still
> using the same 1 connection), but I have a feeling that because I am using
> Response.Buffer = True My ISP's IIS is classing all of the calls as one
> and
> generating a timeout because of the time it is taking to do everything
> before it returns it all. Could this be the case?
>
> I don't want to do the classic answer of increasing the timeout delay, as
> I
> think I would be disguising a problem.
>
> Rgds
>
> Robbie
>
>
> "Michael D. Kersey"
> news:OpIWpIDrEHA.3848@TK2MSFTNGP14.phx.gbl...
> Laphan wrote:
>> Hi All
>> Could somebody outline what are the pluses and minuses of using
>> Response.Buffer = True at the top of my ASP pages.
>> I was told by a poster a long time ago that using this command if you can
>> get away with it gives a better output (?!?!?), but I never found out
>> what
>> he meant by getting away with it or what he meant by a better output.
>> Thanks
>> Laphan
>
> Ken Schaefer's analysis is spot on.
>
> A little IIS history:
> IIRC IIS4 and IIS3 had buffering *disabled* (FALSE) by default. But
> buffering is enabled (TRUE) by default for IIS5 and later versions.
> That may explain why the poster you referenced suggesting setting
> Response.Buffer = TRUE.
>
> So while it is no longer _usually_ necessary, if there is a need to
> enable buffering (e.g., the code includes calls to Response.Clear), then
> you should keep the statement in your code.
>
> Good Luck,
> Michael D. Kersey
>
>
>
>
>
Interesting.
Agree with all that has been written.
Just adding my two cents here... with buffering on, my server often fails to
deliver the whole output from an ASP page to the client. This may well be a
network problem somewhere along the line, but with buffering off the problem
occurs a lot less often.
I have been through this all with MS Support who drew a blank and blamed it
on the network. I was curious how the buffering state affected the problem
and also why the problem occurred less often when I put SQL server on to the
same machine rather than connecting to it on a different machine.
Hmm....
"Astra"
news:e16IVqErEHA.1204@TK2MSFTNGP12.phx.gbl...
> Hi Guys
>
> Thanks for the replies.
>
> The reason I wanted to know any negative sides to this is that the site
that
> I have currently done is experiencing a lot of server timeouts even though
> the script execution should be an enormous burden.
>
> I used .GetRows on all of the DB retrieval work thinking that this would
> give better speed (I use about 3 or 4 DB query calls per page whilst still
> using the same 1 connection), but I have a feeling that because I am using
> Response.Buffer = True My ISP's IIS is classing all of the calls as one
and
> generating a timeout because of the time it is taking to do everything
> before it returns it all. Could this be the case?
>
> I don't want to do the classic answer of increasing the timeout delay, as
I
> think I would be disguising a problem.
>
> Rgds
>
> Robbie
>
>
> "Michael D. Kersey"
> news:OpIWpIDrEHA.3848@TK2MSFTNGP14.phx.gbl...
> Laphan wrote:
> > Hi All
> > Could somebody outline what are the pluses and minuses of using
> > Response.Buffer = True at the top of my ASP pages.
> > I was told by a poster a long time ago that using this command if you
can
> > get away with it gives a better output (?!?!?), but I never found out
what
> > he meant by getting away with it or what he meant by a better output.
> > Thanks
> > Laphan
>
> Ken Schaefer's analysis is spot on.
>
> A little IIS history:
> IIRC IIS4 and IIS3 had buffering *disabled* (FALSE) by default. But
> buffering is enabled (TRUE) by default for IIS5 and later versions.
> That may explain why the poster you referenced suggesting setting
> Response.Buffer = TRUE.
>
> So while it is no longer _usually_ necessary, if there is a need to
> enable buffering (e.g., the code includes calls to Response.Clear), then
> you should keep the statement in your code.
>
> Good Luck,
> Michael D. Kersey
>
>
>
>
>
Dear Dave
I know it's been a long time, but I just wanted to come back to you to let
you know that my server config is the same, in that my web server and db
server are on separate machines, and that since I removed the
response.buffer line I have had virtually zero timeout problems. Hopefully
it will remain this way.
Rgds
Laphan
David Morgan
news:e2dYEfLrEHA.3900@TK2MSFTNGP10.phx.gbl...
Interesting.
Agree with all that has been written.
Just adding my two cents here... with buffering on, my server often fails to
deliver the whole output from an ASP page to the client. This may well be a
network problem somewhere along the line, but with buffering off the problem
occurs a lot less often.
I have been through this all with MS Support who drew a blank and blamed it
on the network. I was curious how the buffering state affected the problem
and also why the problem occurred less often when I put SQL server on to the
same machine rather than connecting to it on a different machine.
Hmm....
"Astra"
news:e16IVqErEHA.1204@TK2MSFTNGP12.phx.gbl...
> Hi Guys
>
> Thanks for the replies.
>
> The reason I wanted to know any negative sides to this is that the site
that
> I have currently done is experiencing a lot of server timeouts even though
> the script execution should be an enormous burden.
>
> I used .GetRows on all of the DB retrieval work thinking that this would
> give better speed (I use about 3 or 4 DB query calls per page whilst still
> using the same 1 connection), but I have a feeling that because I am using
> Response.Buffer = True My ISP's IIS is classing all of the calls as one
and
> generating a timeout because of the time it is taking to do everything
> before it returns it all. Could this be the case?
>
> I don't want to do the classic answer of increasing the timeout delay, as
I
> think I would be disguising a problem.
>
> Rgds
>
> Robbie
>
>
> "Michael D. Kersey"
> news:OpIWpIDrEHA.3848@TK2MSFTNGP14.phx.gbl...
> Laphan wrote:
> > Hi All
> > Could somebody outline what are the pluses and minuses of using
> > Response.Buffer = True at the top of my ASP pages.
> > I was told by a poster a long time ago that using this command if you
can
> > get away with it gives a better output (?!?!?), but I never found out
what
> > he meant by getting away with it or what he meant by a better output.
> > Thanks
> > Laphan
>
> Ken Schaefer's analysis is spot on.
>
> A little IIS history:
> IIRC IIS4 and IIS3 had buffering *disabled* (FALSE) by default. But
> buffering is enabled (TRUE) by default for IIS5 and later versions.
> That may explain why the poster you referenced suggesting setting
> Response.Buffer = TRUE.
>
> So while it is no longer _usually_ necessary, if there is a need to
> enable buffering (e.g., the code includes calls to Response.Clear), then
> you should keep the statement in your code.
>
> Good Luck,
> Michael D. Kersey
>
>
>
>
>