tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Serious mod_jk performance issue
Date Tue, 12 Dec 2006 16:30:13 GMT
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.]

The performance of downloading the file via Apache is good, as is the 
performance when downloading directly from Tomcat.  The performance when 
downloading from Tomcat through Apache via mod_jk is, however, quite 
abysmal.  I'd obviously expect *some* degradation due to the extra 
interprocess hop, but given that this is a just a single-user, 
single-request test, I'd expect that the network would still be the 
limiting factor -- or at least that the degradation would be in the 
order of 25% of less.  What we're seeing, however, is far worse:

    On Windows:

        * Apache 2.0.55, Tomcat 5.0.30, and mod_jk 1.2.20 - Started at
          10 MB/sec ended at 3 MB/sec with mod_deflate disabled (1.5
          MB/sec with mod_deflate enabled)
        * Apache 2.0.55, Tomcat 5.0.30, and mod_jk 1.2.19 - Disabling
          JkFlushPackets only slightly improved performance.
        * Apache 2.2.3 with Tomcat 5.5.20 w/ the native connector -
          Didn't work period.  I didn't have a chance to look into it,
          but the download failed after getting serveral packets (!)
        * Apache 2.2.3 with Tomcat 5.5.20 w/o the native connector - Was
          only slightly slower than going straight through Apache
          about 7-8 MB/sec

    On Solaris:

        * Apache 2.0.55, Tomcat 5.0.30, recent mod_jk - Fairly constant
          4MB/s when going through mod_jk, 10MB/s when just downloading
          via Apache

    [This issue originally was thought to be Windows specific, which is
    why we have many more results for Windows.]

Obviously if our end goal was simple static file transfers we'd just 
share/mirror them to Apache to solve this (we need the load balancing 
flexibility, etc, of mod_jk, so directly using Tomcat is not really an 
option -- nor is doing non-AJP-proxying).  The static file case is the 
simplified reproduction of our real issue, however, which is large file 
downloads from our (Java-based) content store.

We had much better results with Apache 2.2.3 and Tomcat 5.5.20 with 
tcnative, but we really don't want to force a move to 2.2.x and Tomcat 
5.5.x in this case and we've had issues with tcnative (which we *hope* 
may be resolved with 1.1.8).  Overall we'd much prefer to get mod_jk 
working reasonably than to force a disruptive move to 2.2.x right now.

Is this a known issue?  Any pointers as to where/how to look for the 
performance bottleneck?  Some VTune examination showed that almost all 
of Apache's CPU time during this time was in libapr.dll, but that's 
obviously not terribly specific.

Jess Holle

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