I'm using a form to transfer a file to a server (currently on my LAN), but I'm having a huge speed problem. Right now, we're using Apache's FileUpload class:
http://jakarta.apache.org/commons/fileupload/
but we're having horrible speed problems in it (I timed each part, and the times I'm about to give are for FileUpload.parseRequest() ONLY.
For a 1.6MB file, here are the times I calculated (3 trials each, averaged):
Internet Explorer: 21030ms
Konqueror: 3100ms
Netscape: 3070ms
Mozilla: 3111ms
Galeon: 3110ms
My question is, why is IE so much slower, and is there some way around this? I used 2 different computers and got similar results. Because most of our target audience will be using Windows with IE, this is a bit of a problem.
Any idea how to get around it? :(
QuoteAny idea how to get around it?
Don't use IE. :P
Quote from: hismajesty on February 17, 2004, 03:28 PM
QuoteAny idea how to get around it?
Don't use IE. :P
If you aren't going to give useful advice, why are you posting?
iago
specifically stated that he was stuck working with IE.
In the real application, will you still be using it on a LAN? It's possible that IE is just less effective at high speeds. Look at the network traffic and see if you can see any difference. Is the CPU used a lot? Maybe IE is inefficient encoding or deflating or whatever?
Quote from: Adron on February 17, 2004, 06:02 PM
In the real application, will you still be using it on a LAN? It's possible that IE is just less effective at high speeds. Look at the network traffic and see if you can see any difference. Is the CPU used a lot? Maybe IE is inefficient encoding or deflating or whatever?
It will eventually be used both on LAN and on the Internet. I'm not sure about CPU Usage, but I can check on that. I'm also not sure if it scales when the speeds are slower. Like, if it was to be used over the Internet, I'm not sure how it would be affected.
I'm thinking that the problem is with the way IE encodes it, in which case I think I'm suck with the bottle-neck.
and hismajesty - skywing is right. If you aren't going to post anything useful, don't. This is going to be a web application for schools in the city, and I really can't control who uses which browser.
I cant really help much but would you like for me to post your question on a couple of other forums and see if anyone else has a solution?
Did you change the form's encoding property?
Quote from: crashtestdummy on February 18, 2004, 10:41 PM
I cant really help much but would you like for me to post your question on a couple of other forums and see if anyone else has a solution?
If you don't mind. It's not too big of a deal, but it would be nice to know
Storm-id - It's ENCTYPE="multipart/form-data". Isn't that what it has to be for file transfer to work?
Just making sure...was thinking internet explorer might have defaulted to something non-standard?
Quote from: St0rm.iD on February 19, 2004, 05:08 PM
Just making sure...was thinking internet explorer might have defaulted to something non-standard?
Perhaps there is a different way that IE encodes multipart/form-data....
Are you using a Linux/Unix box to host Apache? All the other browsers are Linux-aware, and so perhaps the other browsers (when the get the server ID) encode the form-data (in base64) in big-endian, IE encodes base64 in little-endian, and the server, recognizing IE's gayness, has to convert?
I could be off.... I seem to remember Linux being big-endian, but now I'm having conflicting thoughts about only Motorola being big-endian.....
Perhaps there is a different base64 encoding method? Would it be possible to packetlog this and look at the different encoding methods?
Quote from: Myndfyre on February 19, 2004, 08:17 PM
Quote from: St0rm.iD on February 19, 2004, 05:08 PM
Just making sure...was thinking internet explorer might have defaulted to something non-standard?
Perhaps there is a different way that IE encodes multipart/form-data....
Are you using a Linux/Unix box to host Apache? All the other browsers are Linux-aware, and so perhaps the other browsers (when the get the server ID) encode the form-data (in base64) in big-endian, IE encodes base64 in little-endian, and the server, recognizing IE's gayness, has to convert?
I could be off.... I seem to remember Linux being big-endian, but now I'm having conflicting thoughts about only Motorola being big-endian.....
Perhaps there is a different base64 encoding method? Would it be possible to packetlog this and look at the different encoding methods?
That's a good idea, I *think* I can packetlog there.
Does endianness even matter when using base64?
I just did a demo for my boss, using windows/mozilla and windows/ie, and the difference was 3 seconds versus 57 seconds. Now we're wondering why. I'll break out a packetlogger this afternoon, see if that tells me anything.
Quote from: Myndfyre on February 19, 2004, 08:17 PMI could be off.... I seem to remember Linux being big-endian, but now I'm having conflicting thoughts about only Motorola being big-endian.....
While it is not out of the question that Linux could be made to run on (and might already be available for) big endian architectures, it also runs on Intel/AMD chips, which are little endian.
iago: when you do the packet log, be sure to take a reading of CPU usage over the same period as the packet log, so you can see how much CPU is being used before/during the transfer. From the extreme delay times, I suspect you're going to find that it's using very little CPU time (and is instead just snoozing while it's supposed to be working). Why it would do that, I don't know. However, I can't see anyone coming up with native code so inefficient that it could take 57 seconds to do the work that other browsers are doing in 3.
[Edit: word change.]
this might be a dumb question but did you try the bug query page
http://nagoya.apache.org/bugzilla/query.cgi