tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 6858] New: - Easy & Significant Performance Improvement
Date Mon, 04 Mar 2002 19:44:35 GMT
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: tomcat-dev@jakarta.apache.org
        ReportedBy: tkv@landacorp.com


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
tkv@landacorp.com
Landacorp

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


Mime
View raw message