Hi, that sounds familiar, and is more or less the point of my original inquiry.
I managed to work around the problem using Connect and Response Timeouts for my HTTP Samplers. This is adequate for e.g. stressing an stunnel reverse proxy. However, I'm now facing a situation where I want the crushing load to navigate the site, and where the timeouts will make it impossible to extract good regexes. I guess the test plan will have to "flatten out" somewhat, fetching e.g. the Homepage w/o timeout, then repeatedly "clicking" different links found there (I hope that will work at all). In all, I have found the ability to use timeouts in requests for generating huger loads a large plus for Jmeter. The apache benchmark will never exceed the server's max req/s, and httperf, while it will easily do that, has performance/stability issues of its own. Note that timeouts will result in a higher number of requests, but that your webserver will still not be stomped the same way it would be by a large number of real clients, since due to the very timeouts, it won't notice many of them. I was going to see wether Jmeter in the cloud will generate more stress, but I doubt it, because of the effect you described. If anyone has more findings towards that end, it would be much appreciated. Cheers, Felix On 07/26/2010 10:32 PM, William Oberman wrote: > Well, this is weird/irritating. No matter what I do I can't create > more than certain amount of load with JMeter. For example, if I run > one server at full throttle, I might get 75 req/sec. If I run two > servers with the same size thread pool, I then get ~37 req/sec. If I > run three servers with the same size thread pool, I get 25 req/sec. > And so on. > > I guess this problem is more complicated than I thought without Jmeter > having a specific feature to generate constant inbound load (or > dropping connections slower than X seconds, which I think would also > work) > > will --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
