I started the timeout angle last night, and it was showing similar promise (with similar flaws), but it's great to know I'm on a good path!
One idea I had overnight (the brain doesn't turn off, even when sleeping I guess): for things that require a full result (to parse the output): -Add a two new variables "XYZcount" and "maxXYZ" (if the resource to be parsed is XYZ) -Add two if's: count < max, count >= max -When less than max, don't have timeouts on XYZ, increase count after completed parsing XYZ, decrease count when complete with all child tasks -When >= max, put a timeout on XYZ I think by playing with total number of threads, and number of threads that do a "full XYZ" interaction, I can generate fairly high request load while simultaneously generating "real load". Or an easier option might be having two scripts, one normal & one with timeouts, and running them both at the same time? will On Tue, Jul 27, 2010 at 2:27 AM, Felix Frank <[email protected]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
