yeah, the load line is totally synthetic. honestly, I don't know which approach is best. I tend to think of things a certain way, which is based on work experience. I think adding an additional line might be good. what about
current used /current heap current heap / max heap for what I do, the heap rbehavior is a better indication of application performance. under constant load, the line would show a regular pattern. A poorly written app would show erractic heap usage, which indicates a potential problem. For example, I tend to profile my webapps for 1million requests and see if the thread and memory usage reach a regular pattern after a few hours. If it doesn't, I profile it with OptimizeIt and track down the issue. I probably won't have time to work on it this week, but next weekend I may have time. peter lin On 8/18/05, Jonathan Oexner <[EMAIL PROTECTED]> wrote: > 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]
