[TYPO3-v4] Core performance for 4.6 and beyond

Christian Kuhn lolli at schwarzbu.ch
Thu Feb 10 21:28:24 CET 2011


Hey.

On 02/10/2011 09:01 PM, Dmitry Dulepov wrote:
>> Simple technical reason: memcache is a flat key-value store, but the
>> caching frameworks must tag entries. So we try to push some structure
>> into memcache which is a clear misuse, this is the main reason why
>> memcache is not the ideal backend with the caching framework. Maybe we
>> should come up with a hybrid backend: tags and relations in sql or some
>> other persistent storage, data in memcache. This might work out much
>> better.
>
> This is a good idea! Having tags in the DB could be much better.
> Especially if it uses "INSERT DELAYED".

Nice idea! Never played with 'insert delayed' before.


>> Yep, memcache can easily handle >50k reads / s on a single server. I'm
>> aware of that. In general I'd love to use memcache too ...
>
> So, should we improve that? I think it is important because people will
> naturally try memcache.

Would be great! For the cf backends I currently have two things on my 
radar: A garbage collection for memcache and apc to reconstruct cache 
integrity (not 100% sure if it can be done), and maybe a xcache backend 
similar to apc. Furthermore the 'memcache delete doesn't always work' 
issue in core list nags me. After that I'll try to do some tests with a 
hybrid db/memcache backend, the idea is worth some tests. A db/file 
combination would be nice as well to create a fileBackend with 
reasonable findByTag() speed (and not loosing the PhpFrontend feature).


Thanks for constructive answer
Christian


More information about the TYPO3-project-v4 mailing list