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 <dorma...@rydia.net> 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 <dorma...@rydia.net>: > > 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 > <erichasem...@gmail.com>: > > > 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 > <m...@ryanmccullagh.com> wrote: > > > I'm willing to help out in any way possible. What can I > do? > > > > > > -----Original Message----- > > > From: memcached@googlegroups.com > [mailto:memcached@googlegroups.com] On > > > Behalf Of dormando > > > Sent: Wednesday, January 7, 2015 3:52 AM > > > To: memcached@googlegroups.com > > > 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 memcached+unsubscr...@googlegroups.com. > > > 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 memcached+unsubscr...@googlegroups.com. > > > 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 memcached+unsubscr...@googlegroups.com. > > > 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 memcached+unsubscr...@googlegroups.com. > > 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 memcached+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > >
