Simultaneous get performance

[GoogleCodeExporter]

What version of the product are you using? On what operating system?
2.5 on centerOS 5.3

Tell me more...

I tested sequential get vs concurrent get, and found big performance downgrade 
for latter. Here is benchmark data:
Sequential get:     973159766
get with 10 threads:2081959679
get with 50 thread1:7814012833
get with 100 theads:28834871021

You can use attached class to do verification again. Is it on purpose? 

I saw the same performance downgrade when tomcat6 is configured to enable 
execution pool. So this may be a common issue for many tomcat users. 

Original issue reported on code.google.com by smilingai2004@gmail.com on 21 Jun 2010 at 6:59

Attachments:

• CustMemcachedClientTest.java

[GoogleCodeExporter]

It's not clear to me what you're comparing, but your time code is definitely 
not threadsafe.

Wouldn't it make more sense to just compare the time it takes to complete the 
test and then divide by the number of threads?

Original comment by dsalli...@gmail.com on 21 Jun 2010 at 6:21

• Changed state: NeedInfo

[GoogleCodeExporter]

From end user side, it should be accumulative cost for get operations in each 
thread. I update test class to make our target clearer. See new result:
Average cost per req for Sequential get:954672
Average cost per req for 10 threads: 2093709(ns)
Average cost per req for 50 threads: 4931920(ns)
Average cost per req for 100 threads: 10304223(ns)
Average cost per req for 200 threads: 23358403(ns)

By the way, thread safe is not related to benchmark data under current testing, 
right? I found get op can be added to LinkedBlockQueue. Issue 125 has reported 
LinkedBlockQueue performance concern. Is it the same?

Original comment by smilingai2004@gmail.com on 22 Jun 2010 at 2:34

Attachments:

• CustMemcachedClientTest.java

[GoogleCodeExporter]

I would not expect this type of slowdown.

Original comment by dsalli...@gmail.com on 22 Jun 2010 at 2:52

• Changed state: Accepted

[GoogleCodeExporter]

This could just be a matter of the IO thread being overwhelmed with more work, 
or could be related to issue 125

Original comment by ingen...@gmail.com on 31 Aug 2011 at 10:49