On 19/05/2009, ziohausam <[email protected]> wrote: > > > Thanks for your response > > > > sebb-2-2 wrote: > > > > > > Perhaps the test ended abruptly? > > Did you set the test to continue on error? > > > > Are there any conditional controllers in the test plan? > > > > Are there any errors in the jmeter log file? > > > > > > > no continue on error, no conditional controller. > yes there are some exceptions in the JMeter log filte >
And what are these? Don't paste the whole file here, but a few snippets would be useful. > > > sebb-2-2 wrote: > > > > > > Not sure why you need that information, or whether it would mean > > anything if calculated. > > > > > when i have tried this on some famous web applications, i have found that > the variation between optimal throughput with 25 users and actual throughput > is not huge. > for example: > with 1 user : throughput = 3/sec > with 25 users : throughput(optimal) = 3*25 = 75/sec > with 25 users : throughput(Actual) = 60 > performance drawback from speed point of view = 100-60*100/75 = 20% This depends on the test plan, and the hardware. There will be some reduction in the actual throughput that JMeter can generate, as the threads have to share resourcs in the JVM, OS and network. However, it's largely irrelevant for server testing whether doubling the number of JMeter threads doubles the throughput or not. What's generally important is how the variations on load affect the application. For example, with the "famous web applications" did the average response times vary much? What about Max times? If the response times don't vary significantly, then the application is not being affected by the load. If the response times do go up significantly (e.g. over 20%) then there may be a problem with the application, but again that depends on what the application is supposed to handle. Unless the test plan has a throughput timer or similar in it, then the throughput JMeter can generate will decrease as the average response time increases, because JMeter needs to wait for the response before it can send the next request. > but with my application, the drawback reaches 70%. i need to know if i am: > 1- thinking correctly: > 2- thinking correctly but missing some other factors to be added to reach an > accurate drawback percentage > 3- thinking faulty ( not correctly ) That depends on what conclusions you are drawing. Have you looked at: http://wiki.apache.org/jakarta-jmeter/ In particular the links under "General Articles on Performance testing etc. " > > > > sebb-2-2 wrote: > > > > > > Impossible to say without knowing what the performance requirements of > > the server are, and what the test plan is trying to emulate. > > > > However, the fact that there are some errors when increasing the > > number of threads to 25 could indicate a problem with the server. Or > > it could just be an error in the test plan - e.g. it is not correctly > > set up for multiple threads. > > > > > > Test plan is trying to perform a performance test on each function in our > application. this test specifically is for search function. we have maximum > target to keep 2000 concurrent requests works on this function. ( actually, > some customers hits the DB using web services that calls the search function > with thousands of requests ) > > how can i setup the plan for multiple threads? i just use direct settings by > choosing number of users, ramb-up time, and loop count and even sets all to > 0 except number of threats to 25. > > > > sebb-2-2 wrote: > > > > Try running 2, 3 and 4 threads. If these all work, then the test plan > > at least seems to be suitable. > > > > > > yes i will > > > > sebb-2-2 wrote: > > > > Also, the large increase in the maximum sample time from 5secs to > > 69secs needs to be investigated. > > > > > yes good point > > > Thanks for your response > > > -- > View this message in context: > http://www.nabble.com/Analyze-difference-between-1-user-and-25-users-tp23602736p23619555.html > > Sent from the JMeter - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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]
