tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wang <>
Subject Re: Slow downloads through mod_jk on Windows XP
Date Thu, 10 May 2012 22:26:11 GMT
I have solid numbers that I will e-mail in a follow up  by itself so 
it's not lossed in the shuffle.

Some answers to the comments inline.


>> Do you mean that Tomcat performance appears to be the same regardless
>> of version? That's both good and bad... I thought there were some
>> performance improvements to the connectors from 5.5->  6.0. Maybe that
>> was 4.x->5.5.
Yeah, the download performance through AJP and through HTTP connectors 
is fairly consistent from 5.5->6.0->7.0
>>> Tomcat7 is using JDK 1.7 and this is interesting.  The benchmarks
>>> with tomcat7+jdk1.7 vary widely across the board (both through ajp
>>> and direct http to tomcat) from 30s-40sMB/s. Java 1.6 seems alot
>>> more consistent.  Not sure why yet.
>> That is interesting. On the other hand, the server /is/ on a virtual
>> machine, and you never know what other processes are stealing focus.
>> Many VMs are notorious for bad IO throughput (I'm looking at you, 
>> OpenVZ).
I'm using vmware 5 esxi servers on a pretty beefy system.  8 2.8ghz xeon 
cores, 32gb memory and I'm only running a single VM at a time.  Each VM 
is allocated 4GB of memory and 2 cores.  Should be more than enough to 
handle serving up a 450MB iso file.
>> Have you tried bare hardware?
No, unfortunately I don't have access to bare hardware, but as I 
mentioned, the vmware 5 esxi servers are pretty beefy.
> How much control do you have over the VM server?  Seems to me that 
> resources/performance could be not only affected by other VMs but also 
> intentionally throttled.
I have pretty much full control over the VM servers.  There is no 
throttling going on, no resource limits and as I said, I shut down all 
the other VMs just to rule out contention with them.
>> Some tips for this kind of testing:
>> 1. Don't run ab on localhost: all the numbers will be worthless
>> 2. Run ab with a range of concurrencies, including c=1
>> 3. Make /lots/ of requests. IMO, 5 requests is really a pinhole
>> analysis. I would make as many requests as you can over 10 minutes and
>> see what the throughput ends up being.
I actually ran localhost just out of curiosity and while the numbers are 
faster, the performance difference is consistent with a remote host.  I 
don't want to make alot of requests.  I want to see throughput of large 
files becuase this is where we're seeing the slow downs.  Concurrency is 
not an issue.
>>> I'll compare Windows XP performance and Windows 2008 performance
>>> and after that I'll do the same on a Linux VM to get a better
>>> comparison.
>> It will be good to see.
I decided to just do windows.  The numbers I got are enough for me to 
not care at this point.
>>> I plan on doing both local ab requests as well as remote.  The
>>> problem with remote is that our network is busy, so it may account
>>> for some variations but I don't think I can get our IT to segment
>>> me anything for this purpose :(.
>> Just get a crossover cable and use static IP addresses.
Unfortunately no access to additional hardware.
>>> I'm not so concerned about a 25% hit.  I'm really more concerned
>>> with the drop to 4-5MB/s over time that seems to happen.
>> Does this happen locally or only remotely? I wonder if you're hitting
>> some kind of traffic-shaping or QOS rules on your own internal network.
This type of hit occurs for our customers both locally and remotely.

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

View raw message