Bugs item #679655, was opened at 2003-02-03 12:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104754&aid=679655&group_id=4754
Category: Tapestry Group: bug Status: Open Resolution: None Priority: 5 Submitted By: Peter Levart (plevart) Assigned to: Howard Lewis Ship (hship) Summary: Upload component very slow on file uploads Initial Comment: This is for Tapestry 2.3-rc1 When uploading files using Upload component I get roughly 324 kByte/s transfer rate on a 2.4GHz Pentium 4 Linux server (uploading via localhost - browser on the same machine). With two simple modifications to two classes I can get 35x improvement (11.5 MByte/s) on the same machine. Attatched are the diffs to: net.sf.tapestry.multipart.LineInput and net.sf.tapestry.multipart.UploadOutputStream The private DefaultMultipartDecoder.readIntoStream() method would also need some trimming and this could speed up things for another magnitude. But for 2.3 release at least theese two changes could go in. Peter ---------------------------------------------------------------------- >Comment By: Howard Lewis Ship (hship) Date: 2003-02-20 11:39 Message: Logged In: YES user_id=26816 I've processed some of the changes. I've created a JUnit test suite for file uploads. The changes to LineInput and UploadOutputStream work, but the more involved changes to DefaultMultipartDecoder cause problems. My time is limited, some I'm grabbing the low-hanging fruit. Thanks for the contribution! ---------------------------------------------------------------------- Comment By: Peter Levart (plevart) Date: 2003-02-10 08:11 Message: Logged In: YES user_id=346981 I promissed the benchmark. Here it is: On a 2.4GHz Pentium 4 Linux server (uploading via localhost - browser on the same machine) I now get about 19 MByte/s transfer rate, which is about 59 times as fast as with original code in tapestry 2.3.rc1. What is more important than transfer speed now is that I get the performance that is I/O bound. The server while uploading is only consuming about 60% of CPU time. Previously, the upload performance was CPU bound. The next thing about tuning Upload component would be to be able to specify the directory for uploaded file programaticaly and be able to ge the reference to the uploaded File object through the IUploadFile interface. This way one could eliminate file copy when the uploaded files are stored on the server as files (not in database). But that is a feature request not a bug-report. ---------------------------------------------------------------------- Comment By: Peter Levart (plevart) Date: 2003-02-08 14:33 Message: Logged In: YES user_id=346981 Never mind if UploadOutputStream.java is uploaded twice. It is the same file both times (it didn't show up on first upload to SF, but after the second, both showed up). ---------------------------------------------------------------------- Comment By: Peter Levart (plevart) Date: 2003-02-08 14:26 Message: Logged In: YES user_id=346981 I have now modified the DefaultMultipartDecoder.readIntoStream(...) method to be more efficient. I also had to modify the semantics of the LineInput.readLine() method to return null when the stream is already positioned at the EOF. I will produce the benchmarks on monday when I will measure them on the same machine. I belive uploading will be up to 50% faster then with original DefaultMultipartDecoder and buffered input/output streams, which means it will be 50x as fast as it is now in Tapestry-2.3-rc-1... Attatched are the 3 modified source files that superceede previous 2 diffs: - DefaultMultipartDecoder.java - UploadOutputStream.java - LineInput.java ---------------------------------------------------------------------- Comment By: Peter Levart (plevart) Date: 2003-02-03 12:13 Message: Logged In: YES user_id=346981 Forgot to check the upload checkbox. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104754&aid=679655&group_id=4754 ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
