Re: Response.Flush: Differences between IIS 6.0 and 5.0?

From: Bernard (qbernard_at_hotmail.com.discuss)
Date: 09/20/04 

Date: Mon, 20 Sep 2004 23:54:18 +0800

In your previous posting. since IIS 6.0 is now on top of http.sys.
smaller buffer and so on, each flush cause the packet to send....

won't this a nice things to have ? I mean much faster instead of
sending a big buffer one shot ?

.flush() combine with .buffer = true , not a good deal ?

also you mentioned before about a hot fix in sp1.
what was it intent to change ? 

-- 
Regards,
Bernard Cheah
http://www.tryiis.com/
http://support.microsoft.com/
http://www.msmvps.com/bernard/
"David Wang [Msft]" <someone@online.microsoft.com> wrote in message
news:u4w0lZwnEHA.608@TK2MSFTNGP09.phx.gbl...
> I can check on the behavior with the ASP/HTTP.SYS team.
>
> I actually think that IIS6 does not violate your following statement:
> "In other words, I do not expect my ASP script to continue running until
the
> entire response buffer has been sent to the client."
>
> ASP did send the entire response buffer to the client prior to continuing
> running.  You are expecting ASP to wait until the client has ACK'd the
> receipt of the response -- something quite impractical for a network
> application.  The important thing is that ASP maintains the integrity of
the
> network packet order -- but you can never make any assumptions about
> networking timing.
>
>
> The networking stack used by IIS6 (HTTP.SYS) is radically different than
> IIS5 (Winsock), so differences are likely and may not be reconciled
> depending on how serious they are.
>
> -- 
> //David
> IIS
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Anthony Marchesini" <Arm07470@newsgroup.nospam> wrote in message
> news:%235hus1mnEHA.3464@tk2msftngp13.phx.gbl...
> It has always been my expectation and observation that Response.Flush is a
> synchronous operation.  In other words, I do not expect my ASP script to
> continue running until the entire response buffer has been sent to the
> client.
>
> It appears that this is no longer the case under IIS 6.0.  Here's an ASP
> page that I created to document this unexpected (and, for my application,
> undesirable) behavior:
>
> <%
> With Response
>  'Buffer 1 MB of HTML output
>  .Buffer = True
>  .Write "<html><body><!--" & String(1048559, "-") & ">"
>
>  'See how long it takes to Flush to the browser
>  StartTime = Timer()
>  .Flush
>  StopTime = Timer()
>
>  'Output result
>  .Write "Flush took "
>  .Write FormatNumber(StopTime - StartTime, 3, -1)
>  .Write " seconds to send 1 MB to the browser.</body></html>"
>  .End
> End With
> %>
>
> Browsing to this ASP page hosted on an IIS 5.0 server yield the following
> output in the browser:
>
>    Flush took 5.938 seconds to send 1 MB to the browser.
>
> With the following response headers:
>
>    HTTP/1.1 200 OK
>    Server: Microsoft-IIS/5.0
>    Date: Sun, 19 Sep 2004 16:29:27 GMT
>    X-Powered-By: ASP.NET
>    Connection: close
>    Content-Type: text/html
>    Cache-control: private
>
> Hosted on an IIS 6.0 server, I get this output in the browser:
>
>    Flush took 0.016 seconds to send 1 MB to the browser.
>
> With the following response headers:
>
>    HTTP/1.1 200 OK
>    Connection: close
>    Date: Sun, 19 Sep 2004 16:31:22 GMT
>    Server: Microsoft-IIS/6.0
>    MicrosoftOfficeWebServer: 5.0_Pub
>    X-Powered-By: ASP.NET
>    Content-Type: text/html
>    Cache-control: private
>
> The headers don't seem to reveal anything interesting.  I have included
them
> just to prove that there's no transfer encoding or compression going on
that
> would explain the different results from the two servers.
>
> The interesting result is that Flush took almost no time to execute on IIS
> 6.0 and it took nearly 6 seconds on IIS 5.0.  The 6 second result is
> expected if Flush is a synchronous operation since that's about how long
it
> took to receive the page in my browser from both of the servers.  The only
> explanation for the 0 second result on the 6.0 server is that
Response.Flush
> is behaving asynchronously on that server.
>
> While I'm sure that asynchronous flushes would be desirable for many
> applications, it is highly undesirable for mine.  I won't make this post
any
> longer explaining why (unless someone really wants to know), just trust
that
> I have a good reason.
>
> All of this boils down to two questions:
>
>    1) Is this change in behavior documented and expected?
>    2) Is there a way to get the old behavior back?
>
> - Anthony Marchesini
>
>
>

Relevant Pages

  • Re: "secure" file flag?
    ... you really need to flush the on-device cache on each ... > pass to make sure the bit patterns get written to the platter in proper ... A simple algorithm could just mark each buffer with a special ... read all file blocks into buffers that are marked dirty and get the ...
    (freebsd-hackers)
  • Re: Can anyone explain why this is happening?
    ... Is it possible that your writes do not include a local buffer flush ... written file (to guarantee that newly written data have been flushed to ... before it reads from a new file (which also flushes all buffered written ...
    (comp.parallel.mpi)
  • Re: File output buffer overrun?
    ... > old IBM mainframe Fortran 77 compiler to a modern Linux system. ... a 4K buffer, so it sounds like you're getting far enough into the code ... to flush the buffer ONCE but then the code crashes before the next ... more calcs ... ...
    (comp.lang.fortran)
  • Re: Problems with sys.stout.flush()
    ... Carl Banks wrote: ... console until it sees a newline unless you flush the buffer. ... option for python and a few examples from this sitehttp://stackoverflow.com/questions/107705/python-output-buffering ...
    (comp.lang.python)
  • Re: Response.Flush: Differences between IIS 6.0 and 5.0?
    ... You believe that "ASP did send the entire response buffer to the client" ... Response.Flushsimply takes the data out of ASP's buffer and is placing it ... This worked great in IIS 5 and earlier. ...
    (microsoft.public.inetserver.iis)