www.jfileupload.com

I was checking to see how the speed of uploading with JFileUpload compares with the classic way of uploading files. I have always though that it must be the same. I saw no reason why it should be different. In the following graph you have the bandwidth usage for the classic HTML-based upload method on the left, and the JFileUpload on the right.
I've used the same file, with the same network connection to upload the file to the same server. It seems that JFileUpload is not using almost 40% of the available bandwidth to transfer the file. Could you please explain why is that?

Thank you

This is quite important, as we have a large number of GB files to upload and the transfer speed difference will count a lot.

Are you under Windows? or Linux?
Could you try to increase buffer size such as :
<PARAM NAME="buffersize" VALUE="16384">

I experience this under Windows, but it seems to be worse under Mac OS X.
Setting the buffer size parameter helps a lot. Now it's almost as fast as the standard HTML upload, so thank you for the solution.

Is the following warning related to the "buffersize" parameter that I've set?

WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.

No. Ignore this message.

My measurements were not good after setting the parameter. The transfer speed improves but is still far from what you can get using the classic HTML upload. You can see the two methods compared in the attached graph. Could you please tell me why is JFileUpload applet so much slower that any browser, while transferring the file?

You can also see how JFileUpload's speed compares to a Flash based uploader. On the left is JFileUpload and on the right is the Flash uploader.

After analyzing the network traffic it seems that JFileUpload is treating the upload differently.
At a TCP level, the server is sending an "ACK" after every two frames sent by the client. That is after every ~2KB. No wonder it slows down the transfer speed so much.
This is most probably related to the used HTTP implementation. I'm no Java developer, so it will take me long time to troubleshoot the code. It will be of real help, if you could investigate this a bit.

I'm not sure we can control this level. TCP is related to Java socket handled by the Java runtime. HTTP level is handled by a library that relies on Java socket.