On 09/12/05, Peter Lin <[EMAIL PROTECTED]> wrote: > 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.
Unless you can add some variability to the URL to ensure that the cache does not contain the request. > 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] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
