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 the
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
