On Thu, 13 Jan 2005 00:33:47 -0800 (PST), miguel juteau <[EMAIL PROTECTED]> wrote: > Hello, > I'm getting started with JMeter, and I have some > trouble interpreting results. For example, I ran the > following test script on a few pages at > www.apache.org: > nb threads: 100 > ramp-up time: 30 (seconds) > duration: 600 (seconds) > Constant timer: 1000 (milliseconds) > > As I ran the test, I monitored my PC's RAM and CPU > usage, which remained well under 50% at all times. I > also fired some additional requests manually from a > browser while the test was running: response times > were under a second.
Perhaps these were cached ? > However, the aggregate report shows terrible average > and max values. Total average is 6.6 seconds, maximum > values are in the hundreds of seconds. Just checking - the ave/min/max figures are displayed in milliseconds, did you allow for this? Does the Rate figure seem reasonable? > I'm sure these values don't reflect actual server > response times, but rather my PC beeing overwhelmed by > the number of threads. However this doesn't show in > CPU/RAM comsumption. So where is the bottleneck? In > the JVM? How can I measure this? (I know jmeter server > mode would give better results, I just want to learn > how this all works). Actually, server mode as currently implemented uses *more* resources. For the minimum resource usage, remove all unnecessary listeners, and run in non-GUI (batch mode). Try replacing the Aggregate Listener with a Summariser - output goes to the console and the log file - and see if that makes a difference. At high loads, even a fairly simple display such as the Aggregate Listener can slow things down. If you have two different systems (or one fairly powerful one) you could always try running Tomcat or Apache httpd and testing against that. This should show if JMeter is able to handle the load (as well as reducing the load on the Apache web-site!) Or you can replace the HTTP Samplers with JavaTest Samplers,. Unless your system can handle the load with JavaTest samplers, it's very unlikely to be able to handle the load with the additional processing needed for HTTP. > Regards, > Miguel from the Philippines > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
