thanks for explaining. that makes sense now. given the application is caching, having different requests would be crucial for valid measurement. chances are, you'll need to use atleast 4 clients and split the test plan into 4 smaller test plans. this way, it increases the chances that the threads will have a shorter delay between each thread.
in the past, when I've had to test applications with cache, we made it so the cache can be turned off. This way, we can test the impact of concurrent queries, versus the webserver's ability to handle 100 concurrent requests. If your application doesn't have the capability, it's really going to be hard to effectively test the impact of traffic spike. peter On 12/9/05, Iago Toral Quiroga <[EMAIL PROTECTED]> wrote: > > El vie, 09-12-2005 a las 18:49, Peter Lin escribió: > > 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. > > Because the web server is serving a GIS application that has a cache > system. So I need all the requests to be different in order to avoid > cached responses. > > > 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. > > > > I'm not talking about of being able to serve 100 requests in one second > to the clients. What I want to know is what happens at the server when > 100 requests appear simultaneouly. Surely I need a huge bandwidth to > give response to all those requests, but not to get the requests > themselves, which is the point. A http request is very short in size, > let's say 500 bytes, so you don't need a huge bandwidth in order to > receive them. > > So, if I can receive 100 simultaneous requests, what will happen to my > server? will it crash? will it refuse connections? will it be able to > continue working? at which performce? etc... that is what I want to > know. > > > 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] > > > > > > > -- > Abel Iago Toral Quiroga > Igalia http://www.igalia.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
