Last modified: 2010-05-15 15:33:23 UTC
When the objectcache table is used, there are redundant deletions (for expiry) within db connection sessions, as well as across them. The following patch avoids repeating the deletion within a db connection session.
Created attachment 238 [details] REL1_4 patch for ObjectCache.php
The previous patch also applies to HEAD.
I wonder if it might be better to do delete only as an occasional garbage collection step, and do an expiration check explicitly on load.
(In reply to comment #3) I had wondered the same thing, but I could not think of a way to schedule garbage collection across all requests without adding to the database I/O or adding another process. Although adding an expiry check to the lookups may help future optimisations probably at the cost of another index. There are other inefficiencies in the objectcache table mode, but as the first patch immediately halves the deletions for expiry in local tests, it seems useful to include in v1.4 before the next release. AFAIK, the objectcache table is not used on the Wikimedia sites.
The simple way for for scheduling garbage collection in this environment is to use a probability trigger with a random number. The recentchanges old rows purge works this way: on roughly 1 in 1000 edits it'll do the purge. And yes, objectcache is pretty suck; I wrote it as a quick hack for when memcached is not available so it's not super. :)
Applied a slightly altered version of the patch (separated garbageCollect() logic from expireall() action).
