Our maintain team trend to be conservative, especially on the basic
software relative to performance. so I think it is rare possible to post it
to the production recently. But I write a pretty convenient tools in Python
for an A/B test. The tool can fake traffic of random expire-time and random
length, and also can specify the weights of different expire-time and
length, and lots of other functions. It is almost completed, and I can post
a result next Monday.

On Fri, Jan 16, 2015 at 11:12 AM, dormando <[email protected]> wrote:

> If you want?
>
> What would make you confident enough to try the branch in production? Or
> do you rely on your other patches and that's not really possible?
>
> On Thu, 15 Jan 2015, Zhiwei Chan wrote:
>
> >   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:
> >
> > 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.
> >
> >
>

-- 

--- 
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.

Reply via email to