I try to use real traffic of application to make a compare test, but it seems that not all of guys use the cache-client with consistent hash in dev environment. The result is that the traffic is not distributed well as I supposed. Should I fake the traffic and make a compare test instead of real traffic? e.g., fake the random expire-time keys traffic to set and get for memcached.
--------------- host mc56 installs the most update LRU-rework branch's memcached with option likes "/usr/local/bin/memcached -u nobody -d -c 10240 -o lru_maintainer lru_crawler -m 64 -p 11811"; host mc57 install the version 1.4.20_7_gb118a6c's memcached, with option likes "/usr/bin/memcached -u nobody -d -c 10240 -o tail_repair_time=7200 -m 64 -p 11811", I sum up the stats of all memcache instances on the host and make followings analysis: [image: Inline image 1] On Wed, Jan 14, 2015 at 1:58 AM, dormando <[email protected]> wrote: > Last update to the branch was 3 days ago. I'm not planning on doing any > more work on it at the moment, so people have a chance to test it. > > thanks! > > On Tue, 13 Jan 2015, Zhiwei Chan wrote: > > > I compile directly using your branch on the test server, and please tell > me if it need update and re-compile. > > > > On Tue, Jan 13, 2015 at 4:20 AM, dormando <[email protected]> wrote: > > That sounds like an okay place to start. Can you please make sure > the > > other dev server is running the very latest version of the branch? > A lot > > changed since last friday... a few pretty bad bugs. > > > > Please use the startup options described in the middle of the PR. > > > > If anyone's brave enough to try the latest branch on one production > > instance (if they have a low traffic one somewhere, maybe?) that'd > be > > good. I ran the branch under a load tester for a few hours, it > passes > > tests, etc. If I merge it, it'll just go into people's productions > without > > ever having a production test first, so hopefully someone can try > it? > > > > thanks > > > > On Mon, 12 Jan 2015, Zhiwei Chan wrote: > > > > > I have run it since last Friday, so far no crash. As I have > finished the haproxy works today, I will try a compare test for this > > LRU works > > > tomorrow as following: There are two servers(Centos 5.8, > 8cores, 8G memory) in the dev environment, Both of server run 32 > > memcached > > > instances(processes) with maxmum memory of 128M. One server runs > version 1.4.21, the other runs this branch. There are lots of > > "pools" using these > > > memcached server, and all of pools use tow memcached instances > on different server. The client of pools use Consistent Hash algorithm > > to distribute > > > keys to their 2 memcached instances. I will watch the hit-rate > and other performance using Cacti. > > > I think it will work, but usually there is not much traffic in > our dev environment. Please tell me if any other advice. > > > > > > > > > 2015-01-08 4:21 GMT+08:00 dormando <[email protected]>: > > > Hey, > > > > > > To all three of you: Just run it anywhere you can (but not > more than one > > > machine, yet?), with the options prescribed in the PR. > Ideally you have > > > graphs of the hit ratio and maybe cache fullness and can > compare > > > before/after. > > > > > > And let me know if it hangs or crashes, obviously. If so a > backtrace > > > and/or coredump would be fantastic. > > > > > > On Thu, 8 Jan 2015, Zhiwei Chan wrote: > > > > > > > I will deploy it to one of our test environment on > CentOS 5.8, for a comparison test with the 1.4.21, although the > > workloads is > > > not as heavy as > > > > product environment. Tell me if any I could help. > > > > > > > > 2015-01-07 23:30 GMT+08:00 Eric McConville < > [email protected]>: > > > > Same here. Do you want any findings posted to the > mailing list, or the PU thread? > > > > > > > > On Wed, Jan 7, 2015 at 5:56 AM, Ryan McCullagh < > [email protected]> wrote: > > > > I'm willing to help out in any way possible. What > can I do? > > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto: > [email protected]] On > > > > Behalf Of dormando > > > > Sent: Wednesday, January 7, 2015 3:52 AM > > > > To: [email protected] > > > > Subject: memory efficiency / LRU refactor branch > > > > > > > > Yo, > > > > > > > > https://github.com/memcached/memcached/pull/97 > > > > > > > > Opening to a wider audience. I need some folks > willing to poke at it and see > > > > if their workloads fair better or worse with > respect to hit ratios. > > > > > > > > The rest of the work remaining on my end is more > testing, and some TODO's > > > > noted in the PR. The remaining work is relatively > small aside from the page > > > > mover idea. It hasn't been crashing or hanging in > my testing so far, but > > > > that might still happen. > > > > > > > > I can't/won't merge this until I get some evidence > that it's useful. > > > > Hoping someone out there can lend a hand. I don't > know what the actual > > > > impact would be, but for some workloads it could > be large. Even for folks > > > > who have set all items to never expire, it could > still potentially improve > > > > hit ratios by better protecting active items. > > > > > > > > It will work best if you at least have a mix of > items with TTL's that expire > > > > in reasonable amounts of time. > > > > > > > > thanks, > > > > -Dormando > > > > > > > > -- > > > > > > > > --- > > > > You received this message because you are subscribed to > the Google Groups "memcached" group. > > > > To unsubscribe from this group and stop receiving emails > from it, send an email to [email protected]. > > > > For more options, visit > https://groups.google.com/d/optout. > > > > > > > > > > > > -- > > > > > > > > --- > > > > You received this message because you are subscribed to > the Google Groups "memcached" group. > > > > To unsubscribe from this group and stop receiving emails > from it, send an email to [email protected]. > > > > For more options, visit > https://groups.google.com/d/optout. > > > > > > > > > > > > -- > > > > > > > > --- > > > > You received this message because you are subscribed to > the Google Groups "memcached" group. > > > > To unsubscribe from this group and stop receiving emails > from it, send an email to [email protected]. > > > > For more options, visit > https://groups.google.com/d/optout. > > > > > > > > > > > > > > > > > -- > > > > > > --- > > > You received this message because you are subscribed to the > Google Groups "memcached" group. > > > To unsubscribe from this group and stop receiving emails from > it, send an email to [email protected]. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups "memcached" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > > > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
