You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by miguel juteau <mi...@yahoo.com> on 2005/01/13 09:33:47 UTC
interpreting results
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.
However, the aggregate report shows terrible average
and max values. Total average is 6.6 seconds, maximum
values are in the hundreds of seconds.
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).
Regards,
Miguel from the Philippines
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: interpreting results
Posted by Miguel Juteau <mi...@yahoo.com>.
I will try your different suggestions, thanks a lot!
Miguel
sebb wrote:
>On Thu, 13 Jan 2005 00:33:47 -0800 (PST), miguel juteau
><mi...@yahoo.com> 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: jmeter-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
>
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 1/16/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: interpreting results
Posted by sebb <se...@gmail.com>.
On Thu, 13 Jan 2005 00:33:47 -0800 (PST), miguel juteau
<mi...@yahoo.com> 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: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org