1. Set a ramp-up figure of greater than 0s - to start 1 thread per second use 100s. 2. Have you tried with a lower number of threads first - e.g. 1, 10, 30, 50, 75? 3. Are there any delays in your scripts? If there are no delays then even a fast PC can quickly become overwhelmed (I have seen as few as 20 threads bog down a reasonably fast PC). If you include realistic simulations of user delays in your scripts you should have no problem dealing with 100 or more threads.
Cheers, Scott -- Scott Eade Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au .Mac Chat/AIM: seade at mac dot com On 23/01/2003 5:48 PM, "Cameron Zemek" <[EMAIL PROTECTED]> wrote: > I'm trying to load-test my web application. I am using a thread group > with 100 threads, ramp-up: 0secs, repeat: 10. When I ran this test the > GUI becomes non-responsive and the CPU and memory usage go to 100% > utilization. This is on a 1.2GHz CPU with 378MB (with less then 200MB > used with normal apps opened). > > Using top I get: > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND > 12633 grom 20 0 147M 147M 16188 R 79.7 39.1 2:11 java > 13544 root 14 0 1220 1220 816 R 11.9 0.3 0:02 top > 2451 grom 9 0 7224 6104 4172 S 1.8 1.5 1:06 > gnome-terminal > 1425 root 6 -10 281M 20M 7912 S < 1.3 5.3 7:30 X > 12639 grom 9 0 147M 147M 16188 S 0.4 39.1 0:03 java > 13432 grom 9 0 147M 147M 16188 S 0.3 39.1 0:00 java > 13460 grom 9 0 148M 148M 16188 S 0.3 39.2 0:00 java > 13481 grom 9 0 148M 148M 16188 S 0.3 39.2 0:00 java > 13213 apache 9 0 4736 4736 4520 S 0.1 1.2 0:00 httpd > 13216 apache 9 0 4736 4736 4520 S 0.1 1.2 0:00 httpd > 13227 apache 9 0 4648 4648 4472 S 0.1 1.2 0:00 httpd > 13248 apache 9 0 4736 4736 4520 S 0.1 1.2 0:00 httpd > 13414 grom 9 0 147M 147M 16188 S 0.1 39.1 0:00 java > 13417 grom 9 0 147M 147M 16188 S 0.1 39.1 0:00 java > 13419 grom 9 0 147M 147M 16188 S 0.1 39.1 0:00 java > 13421 grom 9 0 147M 147M 16188 S 0.1 39.1 0:00 java > 13423 grom 9 0 147M 147M 16188 S 0.1 39.1 0:00 java > > I added "-Xmx256m -Xss2m" options to the jmeter startup script. But I > had similar results before this. What is going on??? I have seen in the > archive people posting results such as "I've executed 100 threads in a > single thread group on a Dell laptop with 256M Ram and a 800Mhz > processor with no problems." > > Olav Groehn posted >>>>>>>>>>>>>>>>>>>>>>>> > Usually a PC can handle quite a big number of threads without problems > but think about some other effects that might result in wrong > measurements of server response times: > > A good idea is to monitor the workload of your CPU. If it is around 100% > it might be to much meaning your CPU is overloaded and the measured > response times might be incorrect. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > I also look at using distributed testing. I run rmiregistry as follows > $ export > CLASSPATH=/usr/java/jakarta-jmeter/lib/ext/ApacheJMeter_core.jar:/usr/java/jak > arta-jmeter/lib/jorphan.jar:/usr/java/jakarta-jmeter/lib/logkit-1.0.1.jar > > $ rmiregistry > > then in another terminal I start the jmeter-server script. Then from a > different machine I start the client, but when I try to remote start the > test plan it doesn't seem to do anything. Yet, the access logs indicate > that it was accessed. What going on here??? > > > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
