If noone finds a reason for it, I can go into it during the weekend. I would try to reproduce and research on Solaris. Concerning your data for Solaris: Apache and Tomcat were both on Solaris? The same machine or different? Network between Client (Browser?) and Apache was 100MBit or 1GBit?
Regards, Rainer Jess Holle schrieb: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
