On 20/04/2009, drubix <andrew.schr...@gmail.com> wrote: > > "Yes, each server runs the same test, so the same thread names are > generated." > > > Of course! I've changed the thread group name to include the username of the > account that is being used to log into the system as and everything is > working exactly how I want it. > > Thanks so much for your help! >
Glad it's sorted. > Drew > > > sebb-2-2 wrote: > > > > On 20/04/2009, drubix <andrew.schr...@gmail.com> wrote: > >> > >> Thanks again for getting back to me. > >> > >> I've just got back in to work and have tried running the tests again. I > >> used a simple test plan with 2 requests and a single thread which I ran > >> on > >> two remote servers simultaneously. However, in the results only 3 > >> requests > >> were recorded, two to the first address and only a single request to the > >> second. Also, all of these requests had the same thread name of "Thread > >> Group 1-1". This seems to be why I was so confused and it appeared that > >> only a single thread was being run. I wasn't getting the expected > >> result of > >> four requests so I assumed only a single thread was running. > > > > Ah. There is a bug in 2.3.2 where the log file can be closed > > prematurely, sometimes losing a few samples in the process. The > > workround is to add a short delay at the end of a test to allow the > > last samples time to get processed. This has been fixed in the nightly > > builds. > > > >> When I tried adding a third address to the list, the correct number of > >> requests were made (6) but still, all of the threads have the same name > >> of > >> "Thread Group 1-1". Is this the correct behaviour? > > > > Yes, each server runs the same test, so the same thread names are > > generated. > > > >> The results would be > >> much easier to interpret if one remote server reported itself as "Thread > >> Group 1-1" and the other as "Thread Group 1-2". > > > > You can add the host name to the saved data, or you can use the > > __machineName() function to change the name of the thread group. > > > >> Thanks again, > >> > >> Drew > >> > >> > >> sebb-2-2 wrote: > >> > > >> > On 17/04/2009, drubix <andrew.schr...@gmail.com> wrote: > >> >> > >> >> Thanks for getting back to me. > >> >> > >> >> The reason I thought it shared the load is because of this test I > >> did: > >> >> > >> >> * A simple script making two requests, 1 to google and 1 to youtube > >> > > >> > How many threads? > >> > > >> >> * 2 slave servers > >> >> * 1 master server > >> >> > >> >> When I read the results of this (Result tree view(?) output to file) > >> >> they > >> >> gave. > >> >> Threadgroup 1-1: One request from each slave > >> >> Threadgroup 1-2: One request from each slave. > >> >> > >> >> I assume the first number means the first threadgroup and the second > >> >> number > >> >> refers to the index of the concurrent thread. > >> > > >> > Yes. > >> > > >> >> I would have expected both > >> >> threadgroup 1-1 requests to be made by one slave and both > >> threadgroup > >> >> 1-2 > >> >> requests to be made by the other. Or am I reading this wrong? > >> > > >> > As I wrote before, each slave is sent the whole test plan. > >> > > >> >> Also, if I want multiple servers to carry out the full instruction > >> set > >> >> once, > >> >> should I set the number of threads in the test plan to the number of > >> >> servers, or just 1 thread seeing as each server gets an identical > >> copy > >> >> and > >> >> will carry out a single thread? > >> > > >> > Again, each slave processes the entire test plan. > >> > > >> > So if you want to have 10 threads in total, and 2 slaves, use 5 > >> > threads in the test plan. > >> > > >> >> Thanks again, > >> >> > >> >> Drew > >> >> > >> >> > >> >> > >> >> sebb-2-2 wrote: > >> >> > > >> >> > On 17/04/2009, drubix <andrew.schr...@gmail.com> wrote: > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> I'm attempting to run a load test against our system but because > >> of > >> >> the > >> >> >> way > >> >> >> out authentication is set up each user needs a different IP > >> address. > >> >> I > >> >> >> can > >> >> >> achieve this using IP aliasing and running multiple instances of > >> >> JMeter > >> >> >> with > >> >> >> different local addresses. > >> >> >> > >> >> >> What I'd like to have happen is this: > >> >> >> * Start each slave JMeter instance on a different RMI port and a > >> >> >> different > >> >> >> local IP address > >> >> > > >> >> > OK > >> >> > > >> >> >> * Start the master JMeter instance which distributes the script > >> to > >> >> all > >> >> >> of > >> >> >> the slaves > >> >> > > >> >> > OK, you need to add all the slave addresses to the list of remote > >> >> hosts. > >> >> > > >> >> >> * Have the slaves work through the test script themselves, > >> managing > >> >> >> their > >> >> >> own authentication and cookies > >> >> >> * Repeat the script for a set length of time > >> >> >> * Have all the slaves report back to the master who collates the > >> >> data > >> >> >> > >> >> >> However, JMeter doesn't seem to work that way by default. After > >> >> doing > >> >> >> some > >> >> >> preliminary tests it seems that final results don't necessarily > >> have > >> >> a > >> >> >> correlation between a JMeter instance and the threadgroup it > >> >> operates > >> >> >> in. > >> >> > > >> >> > Not sure what you mean by that. > >> >> > > >> >> >> It seems that JMeter shares the load dynamically rather than > >> just > >> >> >> dishing > >> >> >> out an entire thread group to each instance. > >> >> > > >> >> > Not so, JMeter sends the same test plan to all the slaves > >> mentioned in > >> >> > the remote_hosts property. > >> >> > > >> >> > What makes you think JMeter shares the load? > >> >> > > >> >> >> Unfortunately, as the IPs for > >> >> >> each thread/instance will no longer match up, this doesn't work > >> for > >> >> our > >> >> >> particular situation. > >> >> >> > >> >> >> Is there a way to force JMeter to handle each thread with a > >> >> different > >> >> >> instance > >> >> > > >> >> > No, the entire test plan is sent to all remote hosts. > >> >> > > >> >> >> or, even better, a way to handle IPs (attaching a single > >> username, > >> >> >> password and IP address to a single thread) which would get rid > >> of > >> >> these > >> >> >> problems entirely? > >> >> > > >> >> > The local IP cannot currently be specified per thread, only per > >> JMeter > >> >> > instance, and only for the HttpClient version of the HTTP sampler. > >> >> > > >> >> > It should be possible to enhance JMeter to do this with the > >> HttpClient > >> >> > sampler, but it's highly unlikely this can be done with the Java > >> Http > >> >> > sampler. > >> >> > > >> >> >> Thanks for your help, > >> >> >> > >> >> >> Drew > >> >> >> > >> >> >> -- > >> >> >> View this message in context: > >> >> >> > >> >> > >> > http://www.nabble.com/One-thread-per-instance-on-distributed-system-tp23092193p23092193.html > >> >> >> Sent from the JMeter - User mailing list archive at Nabble.com. > >> >> >> > >> >> >> > >> >> >> > >> >> --------------------------------------------------------------------- > >> >> >> To unsubscribe, e-mail: > >> jmeter-user-unsubscr...@jakarta.apache.org > >> >> >> For additional commands, e-mail: > >> jmeter-user-h...@jakarta.apache.org > >> >> >> > >> >> >> > >> >> > > >> >> > > >> --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > >> >> > For additional commands, e-mail: > >> jmeter-user-h...@jakarta.apache.org > >> >> > > >> >> > > >> >> > > >> >> > >> >> -- > >> >> View this message in context: > >> >> > >> > http://www.nabble.com/One-thread-per-instance-on-distributed-system-tp23092193p23095314.html > >> >> > >> >> Sent from the JMeter - User mailing list archive at Nabble.com. > >> >> > >> >> > >> >> > >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > >> >> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org > >> >> > >> >> > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > >> > For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org > >> > > >> > > >> > > >> > >> -- > >> > >> View this message in context: > >> > http://www.nabble.com/One-thread-per-instance-on-distributed-system-tp23092193p23128708.html > >> > >> Sent from the JMeter - User mailing list archive at Nabble.com. > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > >> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > > For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org > > > > > > > > -- > > View this message in context: > http://www.nabble.com/One-thread-per-instance-on-distributed-system-tp23092193p23129217.html > > Sent from the JMeter - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
