[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