tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wang <aw...@ptc.com>
Subject Re: Serious mod_jk performance issue
Date Thu, 14 Dec 2006 16:31:57 GMT
FWIW, this was also seen in less scientific testing from a linux system 
to an XP client on the same 100Mbit network.

Andy


Jess Holle wrote:
> Apache and tomcat are both on the same Solaris 10 box and the network
> between client (XP) is 100Mbit.
>
> -- 
> Jess Holle
>
> Rainer Jung wrote:
>> 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: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>   
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message