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.
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > 09/09/2006 08:10 AM > Please respond to > "Tomcat Users List" <users@tomcat.apache.org> > > > To > "Tomcat Users List" <users@tomcat.apache.org> > 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. > > http://java.sun.com/docs/hotspot/gc1.4.2/ > http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html > > If you still have memory problems, try a memory profiler like Jprofiler > to detect memory leaks as well as CPU issues. > http://www.ej-technologies.com/products/jprofiler/overview.html > > It would be helpful if you posted any errors in the log files when you > incur the issue. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 09, 2006 1:33 AM > To: users@tomcat.apache.org > Subject: Question about the "compress" setting MIME-Version: 1.0 > > We currently have an app in prod using the original servlet filer > described at > http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html?page=3 , 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: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
