honestly, I don't understand why first request needs to be different for all threads. if the point is to measure an application's ability to handle a sudden spike, it's better to pick a very heavy page and set 1 threadGroup with 100 threads and hit it.
using different thread groups just means you have to ramp for a longer period. I can't stress enough how hard it is to really get 100 concurrent requests. From my experience, what matters more is the system is able to handle a sudden spike gracefully without brinding down the website and return to normal operation once the spike has passed. 100 concurrent requests for an average size webpage 10Kb, means that in an ideal situation one would need a full 100mbit bandwidth. On a 10mbit bandwidth, it's never going to reach that. It's physically impossible. unless the hosting facility has a dedicated OC12, it won't be able to handle 100 concurrent. for some perspective, 40 concurrent requests for 18hrs a day translates to 10million pages views. I know this from first hand experience working at superpages.com. 98% of the sites out there don't get any where near this kind of traffic. peter On 12/9/05, Iago Toral Quiroga <[EMAIL PROTECTED]> wrote: > > Thanks for your comment sebb, > > if I have more than one thread in each thread group my problem is > ensuring that each thread launches a different request, because each > thread will send the same sequence of requests under the threadgroup. > I've tried using an interleave controller, but it deals the requests for > each thread and not for all the threads in the threadgroup :( > > Iago. > > El vie, 09-12-2005 a las 18:01, sebb escribió: > > I suspect part of the problem is that all the threads start at once, > > and having 100 thread groups with only 1 thread in each will make it > > tedious to fix - you'll need to add a gradually increasing delay to > > each of the thread groups. > > What happens if you have fewer thread groups and more threads in each > group? > > You can set the ramp-up for each thread-group to ensure that the > > threads start more evenly. > > > > S. > > On 09/12/05, Iago Toral Quiroga <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I've configured a test with 100 thread groups (one thread per thread > > > group) and added a constant throughput timer to get a 10 requests per > > > second performance. To do so, I configured target throughput to 600 > > > (samples per minute) and selected to compute performance based on all > > > active threads. > > > > > > The result is as expected, I get an average throughput of 10 requests > > > per second, but they are not uniform along the time. What I get is > > > something like this: > > > > > > At second 0, jmeter launches 100 requests to the server. At second 4, > > > jmeter has received all the responses, but because it has lauched 100 > > > requests at second 0, it must wait till second 10 to start another > bunch > > > of 100 requests. What I expect from this kind of tests is getting 10 > > > requests per second *each second*. > > > > > > This kind of behaviour is much more like a repeated peak test than a > > > constant troughput test. I know I can get a more uniform test by > droping > > > the thread count so jmeter would have to wait less time to launch the > > > next bunch of requests, but that is weird and still a trick that does > > > not solve the point of problem at all ¿I'm missing something?, ¿is > there > > > a way to get a more uniform behaviour for this kind of tests? > > > > > > Thanks in advance for your help! > > > -- > > > Abel Iago Toral Quiroga > > > Igalia http://www.igalia.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] > -- > Abel Iago Toral Quiroga > Igalia http://www.igalia.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
