[TYPO3-core] FYI72: enhancements to memcached caching backend

Dmitry Dulepov dmitry at typo3.org
Thu Dec 4 17:22:35 CET 2008


Hi!

Karsten Dambekalns wrote:
> Well, if a cache is not available that should always be recoverable
> (i.e. build the cached info again). Easier said then done, but still true.

I absolutely agree. I think I'll make a separate RFC with exception catching later (may be next week). It should be definitely covered before 4.3 beta 1.

>> About the pool. Using memcached makes sense when it is local. Network
>> delays will kill any benefits of using memcached.
> 
> While a local memcached will be faster accessible than a networked one,
> even that can be a lot faster than no cache. You know of the memcached
> clusters running into terabytes of RAM for facebook and other websites
> of that scale?

I think MySQL will be still faster than networked memcached. I did not do measures, I just have a feeling. Unless it uses a dedicated network interface (card), it will share bandwidth with the real traffic, which is slow...

> We could use connect() if only one server is specified and addServer()
> in other cases, as locally more than one memcached only makes sense[1]
> if you need more RAM than one instance can handle (which should be
> rather rare).

Hmmm, good idea! I'll update the patch using this idea.

> [1] because failover to another memcached on the same machine is useless
> if that machine hangs, is rebooted, whatever.

I saw failover useful in case if one instance dies due to programming error. I plan to run two instances of memcached on my own servers exactly for this reason. I use only memcached now on localhost and it never died yet (very stable!) but backups are never bad :)

-- 
Dmitry Dulepov
TYPO3 core team
In the blog: http://typo3bloke.net/post-details/zend_debugger_goes_64_bit_on_mac_os_x/
My TYPO3 book: http://www.packtpub.com/typo3-extension-development/book


More information about the TYPO3-team-core mailing list