PHP memcached extension

[Alex Stapleton]

Hi Russ ;)

Very short timeouts and machine local status tables (in memcached /  
turckmmcache / eaccelerator / whatever you want ) seem to produce  
pretty reliable fail over for us. Throw in some timeout's and  
register_shutdown_functions()s to recheck the server periodically and  
it actually starts to get pretty nice.

As long as your connect() time-out is low enough to merely make it  
look like the page took slightly longer than normal to load, you  
shouldn't have anything to worry about. It means you have a higher  
potential for false positives but we haven't had any of those yet  
with our time-out set to 500 ms.

Even if you use something which has a habit of forgetting about keys  
(e.g. turck) it's not too painful as the failed connection attempt  
ratio still tends to stay low enough to not be particularly noticeable.

On 6 Sep 2005, at 14:12, Russell Garrett wrote:

>
> On 6 Sep 2005, at 13:18, Antony Dovgal wrote:
>
>> Not precisely true.
>>
>> See this pseudo-code:
>> <?php
>>
>> $first_server = new Memcache(...);
>> $second_server = new Memcache(...);
>> $third_server = new Memcache(...);
>> $fourth_server = new Memcache(...);
>>
>> ?>
>>
>> Nothing prevents you from using as much servers as you want in the  
>> same time.
>>
>> I'm a strong believer that it's better to write couple of lines in  
>> PHP and have 100% flexible API then to hardcode some logics into  
>> the extension and have to work around it every time to get the  
>> desired behaviour.
>
> This is what we do at the moment, but the main issue with this is  
> that there's no failover. In order to implement proper failover  
> you'd need to detect when a server has died and record that fact in  
> shared memory (which PHP doesn't have reliably, which is why we're  
> using memcached in the first place), so you don't have to attempt  
> to connect to a dead server every time. This is a big pain.
>
> We don't do proper failover at present (if one of our web nodes  
> dies, our site is unusable), which is why we were looking to use  
> the mcache extension to implement it.
>
> Russ Garrett
> russ at last.fm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20050906/6971d85c/attachment.html