tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat)>
Subject Re: Weird problem: slow upload via Manager
Date Fri, 06 Jul 2018 07:54:30 GMT
On 06.07.2018 01:23, James H. H. Lampert wrote:
> Earlier this week, on a customer AS/400 installation (Tomcat 7.0.67), we experienced
> slowest WAR file upload we've ever encountered: several HOURS to install a roughly 100M
> WAR file (we customarily increase the max-file-size and max-request-size in
> manager/WEB-INF/web.xml from 50M to 500M). This on a system in which a 10M FTP download
> typically takes anywhere from 15 seconds to a minute or so.
> Has anybody ever heard of anything like this happening? Could there be something in the
> customer's firewall that's slowing down what Manager uses to transfer WAR files (I'm
> guessing either HTTP POST or PUT)?
> Any suggestions on alternate ways of getting WAR files onto the box?
Not about that, but maybe some basic info :
- a browser does not natively do PUTs, so I guess POST it is
- when a browser POSTs a file, the content is first Base64-encoded, which typically 
increases the size in bytes by some 30-50%.  Of course the receiving server has to 
Base64-decode the received data, to restore the original file.
- it is not unusual for encoding/decoding code to process all the data in memory, as
a block. This is usually the fastest way, until some treshold is reached where the data 
does not fit anymore in memory all at once. And then there can be a sudden dramatic 
slowdown, as either there is some frantic allocation of additional memory, or swapping 
taking place.  You might want to have a look at tomcat's JVM garbage collection statistics

while such an upload is going on.
- also, whatever is POSTed to a webserver, is usually first accumulated somewhere, until 
the POST is complete. And then the whole POST is processed, parsed into parts, decoded if

need be, and made available to the web application.
- if this all happens via HTTP, it is also quite possible that there is some 
firewall/virus scanning going on, which would add another round of decoding and examining

the POSTed data, which may also be quite sensitive to the size of things.

What I mean is that there is a lot more going on behind the scenes, as compared to a 
simple file transfer via FTP or so. And if each step introduce some additional overhead 
depending on the original POST size, you may have something that looks exponentially (or 
asymptotically) worse in the end. Like 10 MB = 10s., 40 MB = 40s., 50 MB = 50s., 51 MB = 
10 minutes.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message