We have 2 applications to access the memory cache
One is data processing application – it need 4M qps and can be hosted on the same physical server of memory cache. Another is web App application – it needs randomly access memory cache with maximum thousands of qps through network. Sorry we don’t know too much about ehcache . Will it provide network based client API like memcached? Thanks again! On Tuesday, April 17, 2012 5:28:17 PM UTC+8, Rohit Karlupia wrote: > > In that case you are better off using some inmemory java cache...like > ehcache or some simple expiry mechanism over a simple hashmap. Will save > you the cost of serialization. > > rohitk > On Apr 17, 2012 2:53 PM, "yunfeng sun" <[email protected]> wrote: > >> 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.**googleco**de.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.**googleco**de.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. >>>>> >>>>>
