tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Serious mod_jk performance issue
Date Mon, 18 Dec 2006 16:05:32 GMT
Do your results differ when Windows XP is used as the client?

I looked back at all our notes and though we tested with Solaris and 
Windows servers the client was always XP.

Rainer Jung wrote:
> Hi Jess,
>
> I did some simple tests and was not able to reproduce your performance
> observations. Nevertheless I could observe a couple of strange things,
> but I doubt, if they are relevant to most use cases.
>
> First my setup:
>
> Apache 2.0.59 worker with mod_jk 1.2.20 and Tomcat 5.5.17 with normal
> (non-apr) connectors, using Java 1.5.0_06 on an early Release of Solaris
> 10. Hardware Sun T-2000 (Niagara), which means relatively slow CPU but
> good scalability.
>
> I didn't have the system exclusively, but it was rather idle during the
> test.
>
> Client ab from apache 2.0.59. All ab measurements have been verified
> with "%D" in the apache access log. No restarts between measurements, so
> the file was most likely coming from the file system cache.
>
> Client running either on the same machine, or on a SLES 9 SP2, 64Bit AMD
> Opteron connected by 100MBit Ethernet.
>
> Apache and mod_jk compiled with "-mcpu=v9 -O2 -g -Wall". Apache, mod_jk
> and Tomcat configured default (apart from ports and log format), JVM for
> tomcat with a couple of non-default values:
>
> -server \
> -Xms64m -Xmx64m \
> -XX:NewSize=8m -XX:MaxNewSize=8m \
> -XX:SurvivorRatio=6 -XX:MaxTenuringThreshold=31 \
> -XX:+UseConcMarkSweepGC -XX:-UseAdaptiveSizePolicy
>
> File to test throughput had size 316702480 bytes (some .tar.gz I found
> lying around).
>
> 1) local client, i.e. client running on the same machine as Apache and
> Tomcat
>
> A single request took 15.71 sec (mod_jk) (=153.8 MBit/Sec) and 15.61 (TC
> HTTP direct) (=154.8 MBit/sec), the same with 10 consecutive -
> non-parallel - requests gave 157.1 sec resp. 156.8 sec, so this result
> seems to be stable.
>
> Now parallel requests: I used parallelity ("-c" with ab) of 2 4 8 16 32
> and the double amount of requests (4, 8, ...):
>
> Throughput results in MBit/sec, depending on concurrency:
>
>        mod_jk  http
> conc.
> 1      153.8   154.8
> 2      306.3   303.6
> 4      605.5   627.7
> 8     1090.0  1185.5
> 16    1137.7  1161.8
> 32    1210.7  1114.3
>
> mod_jk and HTTP direct behave almost the same for the huge file. We
> saturate the system at about 1100 MBit/second (going via loopback). CPU
> was busy at most 60% during these tests.
>
> This also shows, that mod_jk and HTTP throughput is enough to saturate a
> lot of bandwidth - as long as your IP stack doesn't add to much overhead
> to it.
>
> 2) remote client, i.e. ab running on the SLES 9 SP2 x86_64 machine,
> connected via 100MBit to Apache and Tomcat.
>
> Throughput results in MBit/sec, depending on concurrency:
>
>        mod_jk  http
> conc.
> 1       88.6    89.1
> 2       88.9    89.1
>
> So even with only one request in parallel we saturate the network and it
> does not make sense to measure more than two parallel requests.
>
> 3) Dependancy on file size:
>
> Measuring with local client without concurrency for 50, 100, 200, 300,
> 400, 500, ..., 1000MB:
>
>        mod_jk  http
>   MB
>   50   167.5   234.9 (5 consecutive requests)
>  100   168.8   170.1 (5 consecutive requests)
>  200   168.6   169.8 (2 consecutive requests)
>  300   169.1   169.7 (2 consecutive requests)
>  400   168.9   169.7 (2 consecutive requests)
>  500   168.8   169.4 (2 consecutive requests)
>  600   167.9   168.0 (2 consecutive requests)
>  700   167.8   168.9 (2 consecutive requests)
>  800   168.1   168.6 (2 consecutive requests)
>  900   168.0   168.0 (2 consecutive requests)
> 1000   156.2   214.9 (2 consecutive requests)
> 2000   156.9   214.7 (1 request)
>
> Interestingly the result for 1000M and for 2000M is reproducible. But as
> soon as I switch from the client "ab" to wget or curl (writing output to
> /dev/null) I get the same numbers for mod_jk, but for HTTP I get the
> same result as for mod_jk!
>
> The numbers are slightly better than in the first test, I guess because
> this test was done using a file in the webapps file system, the first
> test was done using a file in another file system symlinked from within
> webapps (but still a local fs). Another possibilty would be, that a
> mkfile generated file has a better block layout in the fs, than a usual
> file, which was growing over time.
>
> All in all I think that throughput for huge files is very good in both
> cases. I would expect, that most often it would be much more intersting
> to inspect scalability and system load (cpu/memory) for massive
> concurrency. When serving large files, downloads will run a long time
> because most often the client side of the connection is not a fat line.
> As a result users will add up in parallel, so one might need to serve a
> few thousands of users.
>
> Regards,
>
> Rainer
>
> Jess Holle schrieb:
>   
>> Mladen Turk wrote:
>>     
>>> Jess Holle wrote:
>>>       
>>>> We're seeing a *serious *performance issue with mod_jk and large
>>>>         
>>> (e.g. 500MB+) file transfers.  [This is with Apache 2.0.55, Tomcat
>>> 5.0.30, and various recent mod_jk including 1.2.20.]
>>>
>>> SunOS dev12.qa.atl.jboss.com 5.9 Generic_118558-25 sun4u sparc
>>> SUNW,Sun-Fire-V210
>>>
>>> Tomcat:8080
>>> Total transferred:      1782932700 bytes
>>> HTML transferred:       1782908800 bytes
>>> Requests per second:    5.60 [#/sec] (mean)
>>>
>>> Apache-mod_jk-Tomcat:8009
>>> Total transferred:      1782935400 bytes
>>> HTML transferred:       1782908800 bytes
>>> Requests per second:    3.68 [#/sec] (mean)
>>>       
>> I'm re-reading this once again and:
>>
>>   1. This seems like a fairly substantial degradation for an optimized
>>      proxy hop, which is what AJP is.
>>   2. I'm interested in MB/sec for 500+ MB (generally binary) download
>>      transfers, not small HTML pages.
>>          * This is significant in that the performance of the transfer
>>            seems to degrade the larger the transfer is.
>>
>>     
>>> Anyhow, why would you like to serve the 500+ MB
>>> files trough mod_jk? The entire point is that you
>>> have the option to separate the static and dynamic
>>> content.
>>>       
>> We have a large, complex content store behind this with dynamic
>> Java-based access control logic, etc.  Also contents change over time
>> with new check-ins, etc, ala normal version control concepts.  While we
>> have more complex things going on in our actual system, the behavior is
>> quite reproducible by just dropping a >500MB file in an expanded web app
>> doc base and requesting it (with JkMount settings appropriate to ensure
>> this is served by mod_jk rather than directly by Apache).
>>
>> The files can be of any type, but our market involves a lot of CAD data,
>> which can be well over 1GB in size.
>>
>> -- 
>> Jess Holle
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>   


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message