Hello Ian, thanks for the interesting replay. If you are getting 2600 q/s with three threads then you are getting 860 q/s
per thread. This is 1.16 ms per query per thread.
This is not fully true, since I'm already saturating the sampler CPU. More or less, the throughput vs threads are these: 1 thread - 1800-1900 qps 2 thread - about 2400 qps 3 thread - 2600 If you went for six threads then at 2600 q/s you would be doing one query
every 2.3 ms per thread. So to keep the load the same you would add a sleep of 1.14 ms. (Since you can't add such a sleep in JMeter you would add a 2 ms sleep but only execute the sleep on 57% of samples. Or you can do the sleep in the sampler, where you can sleep for 1.14ms, and ideally make the sleep time a sampler parameter.)
Now I've zero sleep time. Next thing I'll try is to add it, but I don't think I can get more througput: I'll have to increase the thread number, so os context switching and so forth... certainly this makes a better solution to create a better load profile - I'll certainly do that, but I doubt about throughput increments...
(But I have to say I don't think you are going to get to the same throughput as with the C program. Where the response time of the system under test is so short you are really testing the load generation tool rather than the system under test. In this case you are comparing a flexible, general purpose tool against something custom built for one purpose. But who knows, you might the same throughput.)
I DEFINITELY AGREE - response times are very low with that kind of test. The interesting thing was that most of the sampler time was spent calling a particular JMeter method, so I was hoping for some performance tuning... no JMeter developers here? :)
