Last modified: 2010-05-15 15:33:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1431 - Repeated deletes from objectcache table for expiry
Repeated deletes from objectcache table for expiry
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.4.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-29 14:37 UTC by Zigger
Modified: 2010-05-15 15:33 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
REL1_4 patch for ObjectCache.php (1.00 KB, patch)
2005-01-29 14:39 UTC, Zigger
Details

Description Zigger 2005-01-29 14:37:40 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.
Comment 1 Zigger 2005-01-29 14:39:07 UTC
Created attachment 238 [details]
REL1_4 patch for ObjectCache.php
Comment 2 Zigger 2005-02-03 13:50:23 UTC
The previous patch also applies to HEAD.
Comment 3 Brion Vibber 2005-02-06 07:31:18 UTC
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.
Comment 4 Zigger 2005-02-07 00:30:33 UTC
(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.
Comment 5 Brion Vibber 2005-02-07 00:39:33 UTC
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. :)
Comment 6 Brion Vibber 2005-02-07 03:04:39 UTC
Applied a slightly altered version of the patch (separated garbageCollect() logic from expireall() action).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links