On 4/26/05, Amogh Phatak <[EMAIL PROTECTED]> wrote: > Hi All, > > I needed some help in loading my web application using JMeter. This is > what I've tried so far. > > Load Scenario: > > Apply load in multiple batches of 20 users as follows: > > * Ramp up time for each set of 20 users is 200 seconds. > * Stabilization period of 10 minutes between 20th user and 21st > user, 40th and 41st user etc... > > Approach #1: > > Till now, I've been gradually loading my web application by starting off > multiple instances of JMeter client on a single machine - each instance > adding 20 concurrent user threads. > > Pros: > > * I could go upto 80 simultaneous users (4 instances of Jmeter > client) on 1 client machine. > * Separate log files generated for each instance, hence if there > are failures, I can relate to which user# failed or slowed down. > > Cons: > > * Cannot go very far beyond 80 threads with this approach. > > * I do not get a consolidated .csv result file. > > Approach #2: > > Using JMeter-server option and multiple client machines. > > Pros: > > * Get a nice consolidated report for multiple JMeter clients. > > Cons: > > * Since I can launch only 1 Jmeter instance on the remote > machine, I'll need large number of client machines to achieve the load > scenario > > * I do get a consolidated .csv result file but it is not > possible to figure which user# failed or slowed down.
Not sure I understand this differs from the separate CSV case, beyond having more users in the one file. If you can work out which user it is with 20 users per file, why not with 80? > Can someone help me figuring out Approach #3 to beat the cons associated > with the Approach #1 and #2? > Approach #3 is to use non-GUI mode. This uses far fewer resources than either stand-alone or client-server, so you should be able to run more clients if necessary. CSV files can surely be easily merged by simple concatenation and sorting on the time-stamp? Approach #4 is to use a large number of users, but include a throughput controller. If the throughput value is defined in terms of a property, you can change the property to change the load on the server. The BeanShell server can be used to give access to the property at run-time. To start the server, edit jmeter.properties and define the property beanshell.server.port=9876 (say). Also define beanshell.server.file=../extras/startup.bsh. You can then use a browser to connect to http://localhost:9876/ (or you can telnet to localhost:9877) and you can then send commands to the server, for example: % printprop("user.dir"); % setprop("throughput","100"); You can also create a bsh script, and pass it to the server using the following command: java -cp ..\lib\bsh-2.0b1.jar bsh.Remote bsh://localhost:9876 filename.bsh There's a slight bug in bsh.Remote - it does not seem to exit at EOF on the input file, so you have to stop the process at the end. The script can contain sleep() and setprop() calls as needed. HTH. S. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
