武汉大学z

Sent from my iPhone

On Aug 28, 2010, at 12:48 PM, [email protected] wrote:

>   Today's Topic Summary
> Group: http://groups.google.com/group/memcached/topics
> 
> memcached permissions [4 Updates]
> Surge 2010 Early Registration ends Tuesday! [1 Update]
> Consistent hashing in PHP and Java [2 Updates]
> Help Needed - Rails Cache - Time Based [1 Update]
>  Topic: memcached permissions
> KaiGai Kohei <[email protected]> Aug 27 05:45PM +0900 ^
>  
> BTW, how about getting inclusion of this patch?
>  
> (2010/08/16 14:38), KaiGai Kohei wrote:
>  
> -- 
> KaiGai Kohei <[email protected]>
>  
> 
> dormando <[email protected]> Aug 27 02:02AM -0700 ^
>  
> We're still working on merging down 1.6... but if this exists outside as
> an engine nothing of us blocks you from using it for now.
>  
> I sort of wonder a little about outright pulling it into the tree, since
> that implies we have to maintain it.
>  
> On Fri, 27 Aug 2010, KaiGai Kohei wrote:
>  
>  
> 
> KaiGai <[email protected]> Aug 27 04:57PM -0700 ^
>  
> Sorry for the confusion.
> I intended to talk to maintainer of the standard security policy in
> SELinux.
>  
> It is my job to maintain the selinux_engine.so module. :-)
>  
> Thanks,
>  
>  
> 
> dormando <[email protected]> Aug 27 04:59PM -0700 ^
>  
> Ahhah, thanks :)
>  
> Was uh, scared for a moment the that initial thread had been lost in time.
>  
> On Fri, 27 Aug 2010, KaiGai wrote:
>  
>  
> 
>  Topic: Surge 2010 Early Registration ends Tuesday!
> Jason Dixon <[email protected]> Aug 27 03:33PM -0400 ^
>  
> Early Bird Registration for Surge Scalability Conference 2010 ends next
> Tuesday, August 31. We have a killer lineup of speakers and architects
> from across the Internet. Listen to experts talk about the newest
> methods and technologies for scaling your Web presence.
>  
> http://omniti.com/surge/2010/register
>  
> This year's event is all about the challenges faced (and overcome) in
> real-life production architectures.  Meet the engineering talent from
> some of the best and brightest throughout the Internet:
>  
> John Allspaw, Etsy
> Theo Schlossnagle, OmniTI
> Bryan Cantrill, Joyent
> Rasmus Lerdorf, creator of PHP
> Tom Cook, Facebook
> Benjamin Black, fast_ip
> Christopher Brown, Opscode
> Artur Bergman, Wikia
> Baron Schwartz, Percona
> Paul Querna, Cloudkick
>  
> Surge 2010 takes place at the Tremont Grand Historic Venue on Sept 30
> and Oct 1, 2010 in Baltimore, MD. Register NOW for the Early Bird
> discount and guarantee your seat to this year's event!
>  
>  
> -- 
> Jason Dixon
> OmniTI Computer Consulting, Inc.
> [email protected]
> 443.325.1357 x.241
>  
> 
>  Topic: Consistent hashing in PHP and Java
> Vicente Aguilar <[email protected]> Aug 27 09:19AM +0200 ^
>  
> Hi
>  
> At work we're setting up a multi-layered cluster with a 1st line of 
> web/proxy/cache servers (nginx+memcached) and several layers of PHP-FPM and 
> Tomcat application servers. At the moment we're using memcached just to cache 
> raw HTML pages, not serialized objects: upon a request nginx checks if that 
> URL (key) is on memcached and then serves it, else it proxies the request to 
> the appropriate app server which serves it and saves it to memcached. Pretty 
> basic memcached usage.
>  
> The problem is that we can't get the PHP, Java and nginx implementations to 
> work together, the PHP and Java consistent hashing algorithms don't seem to 
> match. 
>  
> We're using:
>  
> - nginx: http://wiki.nginx.org/NginxHttpUpstreamConsistentHash 
> - PHP: PECL:memcache http://pecl.php.net/package/memcache
> - Java: spymemcached http://code.google.com/p/spymemcached/
>  
> Both the nginx and PHP implementations match, any HTML representation saved 
> by PHP is retrieved by nginx from the same memcached server; but 
> spymemcached's implementation seems to be different and with 2 memcached 
> server only matches 50% of the time, so it's a completely different algorithm 
> and the matches are random. We're using the nginx patch and PECL:memcached 
> with their default configuration, and as for spymemcached we've tried the 
> NATIVE_HASH, CRC32_HASH and KETAMA_HASH algorithms but none of them matches 
> nginx' and PHP's hashing.
>  
> Anybody else here is using memcached in Java and PHP and got them to work 
> together? I've searched the list and this question has been raised several 
> times but haven't find any definitive answer, just the obvious "different 
> libraries may use different hashing implementations". We don't mind switching 
> to other libraries.
>  
> Thanks in advance.
>  
> Regards
>  
> -- 
> Vicente Aguilar <[email protected]> | http://www.bisente.com
>  
> 
> Matt Ingenthron <[email protected]> Aug 27 10:45AM -0700 ^
>  
> Hi Vicente,
>  
> Vicente Aguilar wrote:
>  
> > The problem is that we can't get the PHP, Java and nginx 
> > implementations to work together, the PHP and Java consistent hashing 
> > algorithms don't seem to match.
>  
> We (Dustin Sallings and Steve Yen mainly) did a lot of testing in 
> spymemcached to ensure the hashing was the same between it and libketama 
> in the most recent release. There is a very large test of these in 
> spymemcached. In the process a bug was found and fixed, but it was a 
> very minor bug.
>  
> It was compared to what libmemcached is doing with it's hashing and it's 
> been well verified. More below...
>  
> > raised several times but haven't find any definitive answer, just the 
> > obvious "different libraries may use different hashing 
> > implementations". We don't mind switching to other libraries.
>  
> Assuming you're using the latest spymemcached (which was released some 
> time ago) and a recent pecl/memcached, at least those two should work 
> together. The PHP level wasn't, but the libmemcached ketama and 
> spymemcached ketama are well tested.
>  
> With only two servers, nearly anything could make it be 50% off but it 
> almost sounds like one client is seeing one of the servers as down. In 
> a ketama world, that'd mean put all of it on the remaining up servers 
> (the other one in your case).
>  
> The only other thing to be careful with is perhaps the key (which seems 
> to be a URL in your case?) is getting truncated or treated differently 
> in different places?
>  
> Sorry I don't have any clear answers here, but I can say it's been 
> tested and SHOULD work.
>  
> - Matt
>  
> 
>  Topic: Help Needed - Rails Cache - Time Based
> moses wejuli <[email protected]> Aug 27 11:05AM +0100 ^
>  
> thanks but i'm unavailable at the moment.
>  
>  

Reply via email to