tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Question about the "compress" setting MIME-Version: 1.0
Date Sun, 10 Sep 2006 22:27:17 GMT
The main difference is that Tomcat doesn't build the entire compressed 
response in memory (which is necessary if you need to send a content-length 
header).  Instead, it used chunked encoding to send the compressed content 
out the wire as it comes in from the servlet.

<> wrote in message
> We're using the latest jdk 1.5 release (the server version of the JVM) and
> currently do have the heap min/max set to 1024 . I'll try the other jvm
> options related to GC. I know we tried -Xincgc to no effect.
> We are indeed seeing OutofMemoryExceptions, but at this point the app has
> a few other problems, that I don't believe are related to the compression,
> so the logfiles are pretty confusing (and the app is catching most
> Exceptions, and only printing the message of the exception, not the
> stacktrace).  What is stumping me a bit is that Tomcat flat out dies with
> no conclusive messages in the logs. My best theory so far is that the Gzip
> filter I mentioned below may be allocating at least 4 objects, each with a
> copy of the entire (compressed) response. Each request is grabbing 100K
> increments of a larger file, but the files can get somewhat large (2-3M)
> The filter is basically a SerlvetOutputStream that passes all the writes
> to the GZIPOutputStream which is wrapping a ByteArrayOutputStream. When
> the ServletOutputStream is closed, it gets the byte array from the
> ByteArrayOutputStream, converts it to a String, and writes it to the
> original HttpResponse. This is probably running down the free memory in
> the JVM pretty quickly, causing the gc to run not only frequently while
> the server is under heavy strain, but also each time it is freeing up alot
> of memory.
> That's why I'm very curious to find out in greater detail exactly how the
> "compress" option is working. I'll take a look at the code again as well,
> but if anyone has any experience using the filter from the O'Reilly  book
> (this is the second time I've seen it used in apps), and in particular how
> the Tomcat implementation behaves, I'd greatly appreciate it.
> "Derrick Koes" <>
> 09/09/2006 08:10 AM
> Please respond to
> "Tomcat Users List" <>
> To
> "Tomcat Users List" <>
> cc
> Subject
> RE: Question about the "compress" setting MIME-Version: 1.0
> Sounds like a bandwidth/throughput problem if you are concerned with the
> connector compression attribute.  You may want to try some performance
> tuning with the throughput garbage collector.
> Assuming your problem is an OutOfMemory Error and at least Java 1.4.1,
> try the following VM settings
> -Xmn=1024m
> -Xmx=1024m
> -XX:+AggressiveHeap
> -XX:+UseParallelGC
> -XX:MaxPermSize=128m
> Below is reference documentation.
> If you still have memory problems, try a memory profiler like Jprofiler
> to detect memory leaks as well as CPU issues.
> It would be helpful if you posted any errors in the log files when you
> incur the issue.
> -----Original Message-----
> From: []
> Sent: Saturday, September 09, 2006 1:33 AM
> To:
> Subject: Question about the "compress" setting MIME-Version: 1.0
> We currently have an app in prod using the original servlet filer
> described at
>  , and
> I know  from the comments to the article in the link that there may be
> some issues with it. My question is; how does the built-in tomcat
> implementation, which is activated by the compress="true" attribute on
> the default http1.1 connector improve on the servlet filter mentioned
> above. For context, I should mention that  we're running on Windows 2003
> server, sp1 using Apache Tomcat/5.0.28 on on dual Intel Xeon processor
> with 4Gb of RAM.
> Under various memory settings ranging from giving the heap from any
> interval of  800 - 1500 MB of heap space, the Tomcat server will die
> more or less silently under even moderate load (heavy load kills it
> almost immediately).
> Any help would be appreciated, and as I've mentioned (username jmonstad)
> on the IRC channel, I may be willing to entertain engagements from local
> to Minneapolis, US gurus for $'s
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message