[thelist] load testing tools and concurrency

Peter Loron peterl at standingwave.org
Fri May 16 12:26:26 CDT 2008

Well offhand, based on what you've seen with the timeouts and  
concurrent reads that you have a race condition or a mutex in there  
that is blocking concurrent access. Time for a code review.

I don't know if there is a profiler available for python, but that  
would be another place I'd go.

JMeter may not be an ideal tool if all you need to do is hit the  
server with some concurrent requests. It is really suited for setting  
up a controllable load.

In general, you can get some useful data simply by applying any old  
load to the app. However if you want to get really useful data out of  
the tests, you need to figure out how to generate realistic load.  
First step is to take a look at what the real world usage patterns  
are...what do the users do when they use the app? Pick several of the  
most common ones, and figure out how to get JMeter to replicate those  
actions as closely as possible.

Then you can figure out how many of those actions to apply per unit  
time to simulate a given number of users.

 From there it gets complicated.  :-)


On May 16, 2008, at 7:54 AM, John DeStefano wrote:

> Thanks, Paul and Peter, for recommending Apache JMeter.  Looks like an
> excellent tool; I've played with it for about an hour now and it seems
> to be able to do all I could ask and much, much more.  If you've
> happened to have used JMeter and come up with a tried-and-true Test
> Plan, please pass it on or send along your suggestions for useful test
> components.
> I'd also appreciate your feedback on concurrent requests:
>> Now, as sidebar: this particular application (which was built using
>> MySQL + Python + Apache) seems slow with sequential reads, but even
>> worse when concurrent requests are used.  I'm being told that this
>> isn't possible, since the server should be able to queue requests as
>> they come in, sequential or otherwise.  While that seems evident,
>> sequential reads return results, while concurrent reads (in any
>> quantity: 10, 5, even 2) result in time-outs much more often.  Any
>> thoughts on this?
> Thanks,
> ~John
> -- 
> * * Please support the community that supports you.  * *
> http://evolt.org/help_support_evolt/
> For unsubscribe and other options, including the Tip Harvester
> and archives of thelist go to: http://lists.evolt.org
> Workers of the Web, evolt !

More information about the thelist mailing list