tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
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


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