Bug #21533
closed
Caching Framework: Memcache backend set() is terrible slow if handling entries with many tags
0%
Description
The memcache Backend is very slow if entries with a lot of tags are handled.
Use case:
We have pages that need around 150 tags assigned to a page cache entry. cache->set() in tsfe takes around 3 seconds (!) to write the entry to memcache backend.
Most of this time is eaten up in t3lib_cache_backend_MemcachedBackend->addIdentifierToTags() where identifier<->tag entries are handled.
APC backend seems to use the same logic as memcached, so both are currently unusable if many tags are handled, dbbackend is much quicker in this case (but could be optimized in set() too, if it would INSERT all tag entries at once and not in a loop for each tag).
(issue imported from #M12562)
Updated by Christian Kuhn about 15 years ago
Flush() is really slow as well.
100MB memcache data took several minutes to flush.
Updated by Oliver Hader about 15 years ago
Unfortunatelly yes... iteration over all elements slows down the whole story.
Updated by Christian Kuhn almost 15 years ago
I think we should close this one as "Not fixable".
The performance problems of apc and memcached are a architectural problem. It's based on the fact that both backends are only able to handle flat "id"->"data" relations, while we need id and data with multiple tags.
For the dbBackend INSERT thingie there is now issue #21753 to enable this in t3lib_db.
Updated by Steffen Kamper almost 15 years ago
i think we should let it open to show the lack of tag iteration.