Thanks rohitk! That’s a very good point.
Is it possible to put the application and memcached on the same physical machine and application talk to memcached directly(like IPC) without going thought network stack? On Tuesday, April 17, 2012 4:41:49 PM UTC+8, Rohit Karlupia wrote: > > As per your calculation you would be transfering 4M * 2K about 8Gb of data > per second. That is approx 64 Gbps of bandwidth. Network is going to be > your biggest problem, not memcached. > > rohitk > On Apr 17, 2012 7:04 AM, "yunfeng sun" <[email protected]> wrote: > >> Dear Dormando , >> Your reply is very helpful!! >> The question is just based on our limited knowledge of memcached. >> We will do more investigation with your guide above. >> Big Thanks again!! >> >> Yunfeng Sun >> >> On Tuesday, April 17, 2012 9:02:19 AM UTC+8, Dormando wrote: >>> >>> > The Java application need Get() once and set() once for each changed >>> pair, it will be 50M*40%*2=4M qps (query per second) . >>> > >>> > We tested memcached - which shows very limited qps. >>> > Our benchmarking is very similar to results showed herehttp:// >>> xmemcached.**googlecode.com/svn/trunk/**benchmark/benchmark.html<http://xmemcached.googlecode.com/svn/trunk/benchmark/benchmark.html> >>> > >>> > 10,000 around qps is the limitation of one memcached server. >>> >>> Just to be completely clear; "10,000 qps" in your test is the limit of >>> *one java thread client*, the limit of the server is nowhere near that. >>> If >>> you started ten client threads, each doing gets/sets, you will likely get >>> 100,000 qps. >>> >>> If you edit your java code and fetch 100 keys at once with multiget, then >>> set 100 keys (using binary protocol or ASCII noreply for the sets), it >>> will get even faster still. >>> >>> Then you do all the other stuff I said. I'd be surprised if you found any >>> daemon that's faster than memcached though. >>> >>> >> On Tuesday, April 17, 2012 9:02:19 AM UTC+8, Dormando wrote: >>> >>> > The Java application need Get() once and set() once for each changed >>> pair, it will be 50M*40%*2=4M qps (query per second) . >>> > >>> > We tested memcached - which shows very limited qps. >>> > Our benchmarking is very similar to results showed herehttp:// >>> xmemcached.**googlecode.com/svn/trunk/**benchmark/benchmark.html<http://xmemcached.googlecode.com/svn/trunk/benchmark/benchmark.html> >>> > >>> > 10,000 around qps is the limitation of one memcached server. >>> >>> Just to be completely clear; "10,000 qps" in your test is the limit of >>> *one java thread client*, the limit of the server is nowhere near that. >>> If >>> you started ten client threads, each doing gets/sets, you will likely get >>> 100,000 qps. >>> >>> If you edit your java code and fetch 100 keys at once with multiget, then >>> set 100 keys (using binary protocol or ASCII noreply for the sets), it >>> will get even faster still. >>> >>> Then you do all the other stuff I said. I'd be surprised if you found any >>> daemon that's faster than memcached though. >>> >>>
