[TYPO3-v4] Core performance for 4.6 and beyond

Christian Kuhn lolli at schwarzbu.ch
Thu Feb 10 22:19:18 CET 2011


Hey.

On 02/10/2011 08:57 PM, Dmitry Dulepov wrote:
> François Suter wrote:
>> This discussion is getting pretty troubling. What's the issue exactly?
>> Why is it not recommended to use memcached and how come it is used
>> (apparently successfully) by high traffic sites?
>
> It is due to tags. Memcache can throw away elements if it runs out of
> memory. So it can throw away a block with tag information. So you will
> not be able to clear cache by tags and will get wrong entries. Same for
> APC.

Yep. Correct analysis.

Memcache is by design a set-and-maybe-get cache. It's not constructed 
for anything that must not vanish without noticing. That is what makes 
cache invalidation (tags) very troublesome. Unfortunatly we must have a 
reliable way to invalidate entries.


> Also tag handling for memcache is very inefficient. Sometimes it takes
> minutes to clear cache using tags, which is not acceptable in FE.

Yes. Another problem: memcache has no namespace, it's flat. Truncating 
memcache clears everything, even entries which don't belong to this 
cache, or to this TYPO3 instance at all. Because of that the backend 
always adds the tag 'TYPO3_cachename' (or similar) to each cache entry. 
If a cache is cleared, the backend looks up all entries tagged with this 
tag and deletes them one by one. This problem is only partly solvable 
with a hybrid backend: Still all affected entries have to be deleted one 
by one, or maybe in one big command.

Yet another issue: Maximum data size of a memcache value is 1MB, this 
can not be changed on configuration level. The current backend 
implementation splits data to multiple key-values if it is bigger than 
that. If memcache throws parts of that away, the cache entry is lost (it 
can not be reconstructed fully anymore, get() returns FALSE then).

This post is not complete without saying that redis has a trivial 
namespace implementation (numbers for databases), no serious size 
problem, and it scales even better. Don't take this sentence too serious ;)


Regards
Christian


More information about the TYPO3-project-v4 mailing list