Response.WriteFile very slow on large files

[Buddy Ackerman]

I'm trying to write files directly to the client so that it forces the client to open the Save As dialog box rather than
display the file. On some occasions the files are very large (100MB+). On these files teh time that it takes until the
client displays the Save As dialog can be extrordinarily long (3+ minutes). I don't understand why.

I was initiall using the format:

Respnse.writefile("filepath", offset, length)

but that simply failed with the user getting a "document contains no data" message. Then I switched to using the
following version of the method:

Respnse.writefile(filepointer, offset, length)
That works but again it takes a long time for the user to get the Save As dialog. I have always used the
Response.BufferOutput = False command to theoretically prevent buffering. My server, not initially intending to
be server these large files only has 256MB of RAM. Not much but considering that the files are not supposed to be
getting buffered it should be enough to download files to clients (which is all this server does).

The CPU usage is not an issue as it only goes to about 10% (although not solidly 10%) during the 3 minutes or so it
takes to start writing the file to the client. The disk usage however is a different story, both reads and writes go
through the roof. (writes presumably because it's paging the data since I have so little physical RAM).

So, does response.writefile ignore the BufferOutput property?

Any suggestions about how to improve performance?

--Buddy

[François Lemaire]

This a known limitation of ASP.NET, which comes from the way data is sent
from the worker process to the IIS process (by named pipes). Use
Response.TransmitFile insted of WriteFile (this method is a new method
introduced in .NET 1.1 SP1 I think).

Regards

François

"Buddy Ackerman" wrote:

I'm trying to write files directly to the client so that it forces the client to open the Save As dialog box rather than
display the file. On some occasions the files are very large (100MB+). On these files teh time that it takes until the
client displays the Save As dialog can be extrordinarily long (3+ minutes). I don't understand why.

I was initiall using the format:

Respnse.writefile("filepath", offset, length)

but that simply failed with the user getting a "document contains no data" message. Then I switched to using the
following version of the method:

Respnse.writefile(filepointer, offset, length)
That works but again it takes a long time for the user to get the Save As dialog. I have always used the
Response.BufferOutput = False command to theoretically prevent buffering. My server, not initially intending to
be server these large files only has 256MB of RAM. Not much but considering that the files are not supposed to be
getting buffered it should be enough to download files to clients (which is all this server does).

The CPU usage is not an issue as it only goes to about 10% (although not solidly 10%) during the 3 minutes or so it
takes to start writing the file to the client. The disk usage however is a different story, both reads and writes go
through the roof. (writes presumably because it's paging the data since I have so little physical RAM).

So, does response.writefile ignore the BufferOutput property?

Any suggestions about how to improve performance?

--Buddy

[PatB]

That's a great fix for large files, but there is a known issue with it
running on Windows Server 2003 SP1. It doesn't work. :-(

I've been trying to get a fix or a work around for it, but Microsoft only
has an unsupported fix for it.

--
Pat B
BCC Software, Inc
A BÖWE BELL + HOWELL COMPANY
"François Lemaire" wrote:

This a known limitation of ASP.NET, which comes from the way data is sent
from the worker process to the IIS process (by named pipes). Use
Response.TransmitFile insted of WriteFile (this method is a new method
introduced in .NET 1.1 SP1 I think).

Regards

François

"Buddy Ackerman" wrote:

I'm trying to write files directly to the client so that it forces the client to open the Save As dialog box rather than
display the file. On some occasions the files are very large (100MB+). On these files teh time that it takes until the
client displays the Save As dialog can be extrordinarily long (3+ minutes). I don't understand why.

I was initiall using the format:

Respnse.writefile("filepath", offset, length)

but that simply failed with the user getting a "document contains no data" message. Then I switched to using the
following version of the method:

Respnse.writefile(filepointer, offset, length)
That works but again it takes a long time for the user to get the Save As dialog. I have always used the
Response.BufferOutput = False command to theoretically prevent buffering. My server, not initially intending to
be server these large files only has 256MB of RAM. Not much but considering that the files are not supposed to be
getting buffered it should be enough to download files to clients (which is all this server does).

The CPU usage is not an issue as it only goes to about 10% (although not solidly 10%) during the 3 minutes or so it
takes to start writing the file to the client. The disk usage however is a different story, both reads and writes go
through the roof. (writes presumably because it's paging the data since I have so little physical RAM).

So, does response.writefile ignore the BufferOutput property?

Any suggestions about how to improve performance?

--Buddy

[Bruce Barker]

the "save as" dialog box will not appear until the client has fully
downloaded the file. while switching to TransmitFile lowers server resources
used, it will not reduce the transmit time of a 100mb file by much. the http
protocol is fairly slow for large file downloads (especially on a win2k
client and its piggyback acks).

-- bruce (sqlwork.com)
"PatB" <Pa**@discussions.microsoft.com> wrote in message
news:92**********************************@microsof t.com...

That's a great fix for large files, but there is a known issue with it
running on Windows Server 2003 SP1. It doesn't work. :-(

I've been trying to get a fix or a work around for it, but Microsoft only
has an unsupported fix for it.

--
Pat B
BCC Software, Inc
A BÖWE BELL + HOWELL COMPANY
"François Lemaire" wrote:

This a known limitation of ASP.NET, which comes from the way data is sent
from the worker process to the IIS process (by named pipes). Use
Response.TransmitFile insted of WriteFile (this method is a new method
introduced in .NET 1.1 SP1 I think).

Regards

François

"Buddy Ackerman" wrote:

> I'm trying to write files directly to the client so that it forces the
> client to open the Save As dialog box rather than
> display the file. On some occasions the files are very large (100MB+).
> On these files teh time that it takes until the
> client displays the Save As dialog can be extrordinarily long (3+
> minutes). I don't understand why.
>
> I was initiall using the format:
>
> Respnse.writefile("filepath", offset, length)
>
> but that simply failed with the user getting a "document contains no
> data" message. Then I switched to using the
> following version of the method:
>
> Respnse.writefile(filepointer, offset, length)
>
>
> That works but again it takes a long time for the user to get the Save
> As dialog. I have always used the
> Response.BufferOutput = False command to theoretically prevent
> buffering. My server, not initially intending to
> be server these large files only has 256MB of RAM. Not much but
> considering that the files are not supposed to be
> getting buffered it should be enough to download files to clients
> (which is all this server does).
>
> The CPU usage is not an issue as it only goes to about 10% (although
> not solidly 10%) during the 3 minutes or so it
> takes to start writing the file to the client. The disk usage however
> is a different story, both reads and writes go
> through the roof. (writes presumably because it's paging the data
> since I have so little physical RAM).
>
> So, does response.writefile ignore the BufferOutput property?
>
> Any suggestions about how to improve performance?
>
>
>
> --Buddy
>