[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