MW memcached driver should fall back to PHP's built-in memcached module if available
Closed, DeclinedPublic
Actions

Assigned To

None

Authored By

	Catrope
	Jan 31 2010, 3:26 PM

Description

Presumably, PHP's memcached module (which caused the memcached class to be renamed to MWMemcached because of a naming conflict) is faster than our PHP implementation and supports the same actions.

We should write a wrapper class around the built-in memcached class that coexists with MWMemcached and have wfGetCache() choose which one to instantiate based on class_exists('memcached') .

In the longer term, we should rewrite this horrible infrastructure and have all cache interface classes inherit one abstract class, and move wfGetCache()'s functionality to a static method in that abstract class. We could also have each cache interface class implement isAvailable() so we can move the class_exists('memcached') check to a more logical place.

Version: 1.16.x
Severity: enhancement

Details

Reference: bz22332

Related Objects

Mentioned Here: T234455: Implement our own Memcached client to support pipelined operations (remove dependency on PECL)

Event Timeline

• bzimport raised the priority of this task from to Low.Nov 21 2014, 10:47 PM

• bzimport added a project: MediaWiki-General.

• bzimport set Reference to bz22332.

• bzimport added a subscriber: Unknown Object (MLST).

Catrope created this task.Jan 31 2010, 3:26 PM

Yes, fine, but it's unlikely the PECL client supports the same hash function (an MD5 hash truncated to 31 bits then modulo the server count), so deployment may be tricky.

(In reply to comment #1)

Yes, fine, but it's unlikely the PECL client supports the same hash function
(an MD5 hash truncated to 31 bits then modulo the server count), so deployment
may be tricky.

I'm not saying we should deploy it on Wikimedia (although, if it really is faster, we may want to), just that we should offer this functionality to third-party users. If migrating an existing server farm from one to the other causes issues, perhaps we should have separate cache types for the two so you can configure MW to use the PHP-based client even if the module-based one is available.

Nemo_bis added a project: OKR-Work.Mar 13 2016, 10:15 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 13 2016, 10:15 AM

Aklapper removed a subscriber: • wikibugs-l-list.Apr 12 2020, 9:55 AM

Krinkle edited projects, added MediaWiki-libs-BagOStuff; removed OKR-Work, MediaWiki-General.Jun 5 2020, 4:43 PM

Krinkle moved this task from General to libs/objectcache on the MediaWiki-libs-BagOStuff board.

I'm not entirely sure what this is asking for, but there is a proposal to no longer automatically use or encourage use of the PECL driver at all. This may or may not make this task obsolete.

T234455: Implement our own Memcached client to support pipelined operations (remove dependency on PECL)

The two BagOStuff classes (MemcachedPhp and MemcachedPecl) now share a common base class (MemcachedBagOStuff). However, due to the hashing behaviour (as Tim mentions) we don't automatically toggle between the two. This, and the fact that Memcached requires explicit enabling by sysadmins (not auto-discovered and auto-enabled like php-apcu) is I think enough reason to avoid automatic toggling between the two.

The default one as promoted by the CACHE_MEMCACHED shortcut is memcached-php, which is the more portable of the two and so seems a reasonable default, with memcached-pecl available for use when preferred and available.

MW memcached driver should fall back to PHP's built-in memcached module if availableClosed, DeclinedPublicActions

Description

Details

Related Objects

Event Timeline

MW memcached driver should fall back to PHP's built-in memcached module if available
Closed, DeclinedPublic
Actions