Hi Peter, It seems to me that we're trying to force this one status line to do 2 jobs. Maybe we need a usage line (current usage / max heap) *and* a current heap line (current heap / max heap). Coincidentally, the "Load" line seems a little, umm, "synthetic" anyway, so maybe we could swap it out and add a line for heap size. When the yellow line tries to cross the blue line, your app will flatline. ;)
I'm actually graduated from WPI (note the "alum"), and using JMeter to earn my keep from the Man. On 8/18/05, Peter Lin <[EMAIL PROTECTED]> wrote: > thanks for the feedback. > > On 8/18/05, Jonathan Oexner <[EMAIL PROTECTED]> wrote: > > Hi all, > > I'm just getting started with webapp performance testing with JMeter, > > and I noticed the bug mentioned in the thread 'Possible bug in monitor > > results listener' from late last year, still present in release 2.0.3 > > . I downloaded the nightly 2-1.20050812, only to find that the bug > > "fix" in CVS is still a little off. The memory usage that most people > > want to see (IMHO) is: > > > > current usage / maximum available > > > > as opposed to: > > > > current usage / current heap size > > > > > > They don't really care what the JVM is doing to the current heap size; > > they just want to know the absolute usage, and how close the are to an > > OutOfMemoryError. Additionally, since the *currently allocated* heap > > size will change whenever the JVM decides to change it, using it for > > the denominator makes it very hard to get an idea of the actual usage. > > I'm much too lazy to submit an actual patch, but in > > $JMETER_HOME/src/monitor/components/org/apache/jmeter/monitor/util/Stats.java > > , I changed the two methods below, and the results make a whole lot > > more sense this way. > > In practice this is not true. In most cases, a server will crash > before it reaches the max heap size. I tested tomcat about 2 dozen > times with a wide variety of loads. I actually started with the > assumption that max heap was better, but after I ran some tests, it > became apparent that wasn't true. > > if you were to profile tomcat with verbose GC you would see that often > an application runs out of memory because the JVM is unable to resize > the heap fast enough. this typically happens with a sudden traffic > spike occurs. Under steady constant or semi-constant load, current > usage / current heap is also more accurate. Say for example I set my > max heap to 512Mb. If constant load uses 200, using the max heap > won't tell me much. In fact it will give me a false sense of security. > > also, using the current used / current heap lets you see how the JVM > is resizing the heap and indicates if there is a memory. Several > tomcat developers use Jmeter monitor for that purpose and so do I. If > you don't believe, I would suggest changing it and run 20-30 tests > with varying request rates and thread count. > > I noticed you're attending Worcester Polytech. Are you doing this for a > degree? > > peter lin > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
