hi
Some things to think about
a. Are you including all resources in your jmeter tests (e.g. all embedded
resources like css/images/javascript which may or may not be cached by the
browser).
b. Do you have assertions for all your tests that validate that your
response is as expected (no error messages , expected text etc?)
c. Have you suitably parameterised your jmeter tests (say for e.g. using
different users so that if your application is caching some bits per user ,
then you dont get better results than you should)
d. Have you distributed your tests across multiple machines correctly (500
concurrent users wont normally be supported by a single client machine)?
regards
deepak


On Tue, Jun 23, 2009 at 8:04 AM, Badeau, Kevin (DPH) <
kevin.bad...@state.ma.us> wrote:

> Hello folks,
>
>
>
> We are using jMeter to capacity test an application we are considering
> purchasing.
>
>
>
> When we ramp up to 500 concurrent users jMeter is reporting response times
> under 5 seconds and it appears it is stepping through all the functionality
> we are asking it to do.
>
>
>
> This is very acceptable for us.
>
>
>
> However, while the test is running we try to hit the application manually
> and we find it is unresponsive.
>
>
>
> Manual testing is quick outside of a concurrent jMeter test running.
>
> Manual testing performance degrades as we in range from 100 to 200
> concurrent users.
>
> Manual testing is unresponsive when we run 500 concurrent users.
>
>
>
> jMeter reports response times only degrade by about a ½ second for each
> level of concurrent users we try.
>
>
>
> There seems to be some wide performance variance from what jMeter is seeing
> vs. what we see manually.
>
>
>
> I'm wondering if anyone has any general suggestions as to why this might be
> or how we might go about isolating this anomaly.
>
>
>
> I can provide more specific details if needed but I feel the question is
> pretty basic in terms what we understand the tool is supposed to be
> accomplishing in simulating real world scenarios and benchmarking them.
>
>
>
> Thanks in advance.
>
>
>
> Kevin
>
>

Reply via email to