The problem according to the author is:
When uploading a file to a web server, the upload process generally requires the incoming file to be stored in memory until the upload is complete. If an uploaded file is larger than the available memory, memory usage in general and performance in particular will suffer.And the suggested solution was to read the uploaded data directly from PostedFile.InputStream as small chunks and store them in a database.
I believe the author has totally missed the point in this article.
First: Huge uploaded files are not kept in memory, they are buffered to the hard disk. at least this is true in ASP.NET 2.0 as stated in the msdn:
Files are uploaded in MIME multipart/form-data format. By default, all requests, including form fields and uploaded files, larger than 256 KB are buffered to disk, rather than held in server memory.
Second: The solution claims that reading the file from the InputStream will be a streaming solution that avoid caching the whole file on the server, which is again not true. The ASP.NET code is called after the whole request has already been submitted to the server.
I wished to clarify this by commenting on the article or by sending to the author, but unfortunately, the site does not allow this :( .
2 comments:
I saw ur comment on this article, and then I arrived here, I saw that article u r talking about and I agree with u that handling streaming is on the server side after the page has been submitted to the server.
But the goal is to split the file before storing it in the database and I see its a good solution for many cases.
Hello Islam
The article at (15seconds) provides a right solution for the wrong problem.
It provides a useful way to load BLOBs into a database. (which can help you improve performance in your nice article). But it has nothing to do with how IIS manages uploads.
maybe the author had to make this clear.
Post a Comment