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 Thu, 14 Dec 2006 15:53:56 GMT
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


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