Multi-threaded simpleDB access on multi-core machines doesn't scales

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run some performance test with multiple threads (say 100) on a single,
dual and 4 core machines. I tested specifically with getAttrbutes call.

What is the expected output? What do you see instead?
As we give more cores to the test program, we should see increase in TPS
because of more cpu available. We was observed was no increase in TPS.

What version of the product are you using? On what operating system?
Tested on version 1.5.1 and trunk. EC2 linux.

Please provide any additional information below.
Profiling shows that AWSConnection encode method is the bottleneck.
Basically when using a single key, AWSConnection will create just a single
Mac object and use it for encoding all requests. As per commit comments
this was done to increase performance by avoiding Mac.init overhead. On a
single core systems or when running a test case with single connection,
this enhancement will show improvement in latency, but with multithreaded
code running of multi-core systems this becomes a bottleneck. 

Simple Fix 
- Make the macMap, lastSecret, macLock object instance specific instead of
static
Better Fix
- instead of just having a single cached mac object, have a pool of
initialized mac objects. Instead of blocking the caller when pool is empty
(all cached mac objects are in use), create a new one and cache it once the
caller is done. This strategy will ensure that after some time all mac
objects will come from cache, which will avoid the overhead of init and
also make sure that threads are never blocked.

Original issue reported on code.google.com by iamro...@gmail.com on 18 Mar 2010 at 7:46

[GoogleCodeExporter]

I understand what you're saying. I think the simplest (and requiring the least 
testing and 
overhead) would be to simply keep the Mac local to the object, not static. For 
the most 
part, the objects are re-used, or can and should be, so the first WS call 
invoked by an 
object would incur the Mac.init overhead. Thanks for catching this.

Original comment by dkavan...@gmail.com on 23 Mar 2010 at 9:27

• Changed state: Started

[GoogleCodeExporter]

check in, svn r316

Original comment by dkavan...@gmail.com on 23 Mar 2010 at 9:32

• Changed state: Fixed