DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6858>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6858 Easy & Significant Performance Improvement Summary: Easy & Significant Performance Improvement Product: Tomcat 4 Version: 4.0.1 Final Platform: All OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We have been doing some profiling of our struts application with tomcat 4.0.1. Our application is "tag-heavy" (we use tags everywhere). When profiling our application we noticed a significant amount of time was being spent in the creation of BodyContentImpl. (Using OptimizeIt, it reported %55.00 of our total cpu time was being spent in the constructor!!) Looking into this further....the generated code for a jsp tag appears to construct these indirectly through pageContext.pushBody() and throw them away after the page is rendered. The BIG problem was that for each BodyContentImpl created, a default char buffer of 8K is created. This is MUCH bigger than it needs to be, at least for our struts applications. Most of our tags only output a few characters. On a hunch, I changed the constructor for BodyContentImpl to allocate the starting buffer at 512 bytes. The results were dramatic! We profiled the application again, the application spent (.74%) of its time in the constructor! Thats a 74X difference. This problem was much more pronounced using Sun's Server Hotspot JVM and turning on the "-verbocegc" showed us that we were spending a large amount of our time in garbage collects. Some of them were 12+ seconds!!! ouch. Why? I suspect the large volume of garbage is confusing the garbage collector. We reverted back to the orginal 8K buffer and attempted to play with the Hotspot tuning parameters and we got better performance but it STILL took an unacceptable amount of time to garbage collect....We were getting full GCs each time and some of them were still taking 6 secs. Once we added my hack in for 512 bytes....we saw normal behavior from the garbage collector: Incremental GCs, most under a second, and a the longest collect was 2 secs. There are two solutions that would fix this problem: a) Pooling : Either pool the BodyContextImpl or the char[] buffers. 0r b) Change the initial buffer size to a more sane value. 512 bytes appeared worked out much better in our application...although our application mainly uses struts and most of the tags output less than 512 bytes. Perhaps 1K might be better? Sorry I don't have the "patch" utitility readily available, so here is the change that I made: In BodyContentImpl: >From this: public class BodyContentImpl extends BodyContent { private char[] cb; protected int bufferSize = Constants.DEFAULT_BUFFER_SIZE; To this: public class BodyContentImpl extends BodyContent { private char[] cb; protected int bufferSize = 512; Thanks Tyler Van Gorder [EMAIL PROTECTED] Landacorp -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
