Heh. I had a funny feeling that was going to be the answer. I was curious mostly because the Binary mode seemed to do quite a deal of good for Facebook when it was used. I'm imagining that they cached images so binary was a good idea, but for simple structures like json, it might not make much sense. So thought I would get some opinions :).
I will do some testing Thanks again. I'll post back in case I continue to get stuck after these tests. -Pat _______ Hard to tell but easy to measure. Just try both and measure the difference. thanks! rohitk _______ @Rohitk Thanks for this information! I will pass this on to our IT person. This has dovetailed into another question now. How much of a difference would it be to use the BinaryConnectionFactory and not to use it? -Pat On Sun, Feb 20, 2011 at 11:31 PM, Rohit Karlupia <iamro...@gmail.com> wrote: > Usually the bottleneck would be either cpu or network. > - Check the cpu usage on both client and server machines when this happens. > - Verify your network capacity using some tool. 10Mbps network will choke > around 1.25MBps. This could be because of NIC speed on one of the machines > or because of some switch in between. > > thanks! > rohitk > > > On Mon, Feb 21, 2011 at 12:14 PM, Patrick Santora <patwe...@gmail.com>wrote: > >> @Dustin: Thanks for the great feedback Dustin. >> >> We are hitting it with our monitoring software, but I believe that's for >> every 5 min only. The 80MB was a bad metric on my part I believe. The >> monitoring systems say 80M bits per second. So that's my fault. >> >> What are your thoughts about either using or not using the >> BinaryConnectionFactory when instantiating the client? >> >> @All: Here is the stats trace right before it started to complain again: >> STAT pid 30375 >> STAT uptime 15937 >> STAT time 1298266239 >> >> STAT version 1.4.5 >> STAT pointer_size 64 >> STAT rusage_user 93.698755 >> STAT rusage_system 369.808780 >> STAT curr_connections 811 >> STAT total_connections 1747 >> STAT connection_structures 870 >> STAT cmd_get 514387 >> STAT cmd_set 50233 >> STAT cmd_flush 1 >> STAT get_hits 503458 >> STAT get_misses 10929 >> >> STAT delete_misses 0 >> STAT delete_hits 0 >> STAT incr_misses 0 >> STAT incr_hits 0 >> STAT decr_misses 0 >> STAT decr_hits 0 >> STAT cas_misses 0 >> STAT cas_hits 0 >> STAT cas_badval 0 >> STAT auth_cmds 0 >> STAT auth_errors 0 >> STAT bytes_read 6356720419 >> STAT bytes_written 63755346246 >> >> STAT limit_maxbytes 536870912 >> STAT accepting_conns 1 >> STAT listen_disabled_num 0 >> STAT threads 4 >> STAT conn_yields 0 >> STAT bytes 3537642 >> STAT curr_items 3631 >> STAT total_items 50233 >> STAT evictions 0 >> STAT reclaimed 13167 >> END >> >> >> On Sun, Feb 20, 2011 at 10:33 PM, Dustin <dsalli...@gmail.com> wrote: >> >>> >>> On Feb 20, 11:22 am, Patrick Santora <patwe...@gmail.com> wrote: >>> >>> > Queries a second are I believe around 16 to 20. >>> >>> That's close to nothing. >>> >>> > STAT connection_structures 904 >>> >>> Nearly 1,000 connections. >>> >>> > STAT get_hits 192557 >>> > STAT get_misses 4276 >>> >>> Decent hit rate. >>> >>> > STAT bytes_read 1466964195 >>> > STAT bytes_written 15148562971 >>> >>> That's almost 80K transferred per successful get request? That's >>> 1.5MBps given your 20 req/s estimate. Are you perhaps hitting it with >>> stats requests really hard (that's not shown here)? >>> >>> The overall average (given an uptime of 22821 seconds) is about 648 >>> kBps. I don't know how you're getting 80MBps, but if it's memcached, >>> it would've had to have sent all of those bytes in three minutes. >>> >>> > STAT limit_maxbytes 536870912 >>> >>> How much RAM does your server have? >>> >>> > STAT bytes 2532172 >>> > STAT curr_items 2657 >>> >>> This is showing an average of closer to ~1k per item. Something >>> doesn't seem to be adding up here... >> >> >> >
