Hi,
I have a question about using the type with a
multipart/form-data HTTP POSTed form on IIS.
Does IIS always stream the POSTed file data to memory, or does it
stream to disk if memory is short? I am worried about our server
falling over if lots of people suddenly upload files with a total of
more than the servers available memory..
"Chris Ashley"
news:84be9bcb-2fd3-424a-b44c-49fb23483f23@d27g2000prf.google groups.com...
> Hi,
>
> I have a question about using the type with a
> multipart/form-data HTTP POSTed form on IIS.
>
> Does IIS always stream the POSTed file data to memory, or does it
> stream to disk if memory is short? I am worried about our server
> falling over if lots of people suddenly upload files with a total of
> more than the servers available memory..
It will stream in to memory. However don't forget that the addressable limit
of any process is 2GB (or 3GB if booted with the 3GB switch). You can
ensure that the process can access as much addressable space it can by
making sure your page file is adequately sized.
If you need more space and are using IIS6 you can increase the worker
process count on the the application pool that you site runs in. You can
then add more physical memory to the server as well as increase pagefile
size to improve the server's capacity to handle uploading demand.
--
Anthony Jones - MVP ASP/ASP.NET
On Nov 26, 1:31 am, Chris Ashley
> Hi,
>
> I have a question about using the type with a
> multipart/form-data HTTP POSTed form on IIS.
>
> Does IIS always stream the POSTed file data to memory, or does it
> stream to disk if memory is short? I am worried about our server
> falling over if lots of people suddenly upload files with a total of
> more than the servers available memory..
The answer depends on the URL you use to handle the POST.
IIS itself does not stream or do anything with the POST data. It just
gives server-side application access to that data.
The application executed by the URL controls how to stream the POST
data, so it can choose to stream it to disk, or buffer to memory. For
example, application frameworks like ASP and ASP.Net buffer a what is
read via Request.BinaryRead() to memory, but the application can
choose to write that data to disk or to continue buffering in memory.
Thus, IIS does not control streaming behavior at all. In fact, it is
not possible for IIS to gracefully limit POST data size (i.e. you
can't prevent people from uploading 4GB files gracefully) because the
HTTP spec around this behavior is confusing from a backward-
compatibility point of view (i.e. 100-continue is supposed to allow
this for HTTP/1.1 clients and servers, due to existence of HTTP/1.0
servers and clients, even HTTP/1.1 clients tend to violate and ignore
100-continue logic).
As Anthony mentions, there are a variety of tricks that one can do on
a 32bit Windows OS to work with applications that buffer to memory to
provide it the memory it wants, but those are work-arounds.
The only way to get nice control of upload/download sizes is to invent
and use your own protocol with XML Http, like GMail or Hotmail.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//