On 14/04/2008, ansonyc <[EMAIL PROTECTED]> wrote: > > Hi Sebb, > > Thanks for your response. I'm concerned about the limitations of the remote > servers, and wonder if we can document some some general advice and tips for > situations to avoid, in achieving better scalibility for jMeter through > remote servers. And if there are specific cases we all agree should work > better in a certain way, perhaps improvements can be made. > > That said, you have a good point about network limitations. The controller > and the remote server are communicating over a VPN connection, and are on > different networks - a situation I'm used to using other load running tools. > Instead, I'm thinking of trying: > > 1. To put the controller and remote server on the same remote network so > that they aren't communicating over VPN anymore. > > ... as well as reducing some of load on the single JMeter client by: > > 2. Disabling Graph Results and Aggregate Results and sticking only with a > Summary Report, and/or > > 3. Reading up on non GUI JMeter operation and trying that out. > > What do you think of my above options? Can you speculate on the relative > merits of each of the above points, in my goal to achieve near-linear > scalability of throughput using remote agents? >
Some of this is already documented: http://jakarta.apache.org/jmeter/usermanual/best-practices.html#lean_mean For minumum resource usage, non-GUI mode is the way to go. Client-server mode is always going to be more resource intensive. > Regards, > ANSON > > > > > sebb-2-2 wrote: > > > > On 11/04/2008, ansonyc <[EMAIL PROTECTED]> wrote: > >> > >> Hi, > >> > >> I'm starting to use remote servers but having trouble understanding its > >> throughput behaviour and how it distributes the threads in the Test > >> Plan.. > >> > > > > The test plan is sent to all the remote servers and executed there. > > > > All the responses are returned to the single JMeter client, so this > > can become a limiting factor, as can the network between the two. > > > >> I have a Test Plan that achieves about 10 requests/second run locally > >> against a target system, when using 20 threads. I take this same Test > >> Plan > >> with the same number of threads and run it on a single remote server, > >> controlled by the original machine. I get about 5 requests/second, > >> about > >> half the total number of Samples in the same period of time. The > >> response > >> times are similar, and Uniform Random Timer settings are identical, so > >> it's > >> almost as if the remote server is running 10 threads rather than 20. > >> > >> I then add a second remote server and run the same Test Plan remotely > >> over > >> those two. Strangely, I get about 2.5 requests/second in total! > >> > >> I'm observing requests per second through a Summary Report, and an > >> Aggregate > >> Report. I also happen to have a Graph Results running. > >> > >> Here's the kicker: just to make sure I'm not running into capacity > >> problems > >> of the specific remote machine, I copy my .jmx script directly over to > >> one > >> of the remote servers and run it LOCALLY from there. I get the full 10 > >> requests per second I'm expecting. > > > > So the problem is in the network or the JMeter client or both. > > > >> Regards, > >> ANSON CHAN > >> > >> -- > >> View this message in context: > >> > http://www.nabble.com/The-more-remote-servers-I-use%2C-the-less-throughput-I-get-tp16629935p16629935.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] > > > > > > > > > -- > View this message in context: > http://www.nabble.com/The-more-remote-servers-I-use%2C-the-less-throughput-I-get-tp16629935p16678093.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]
