PHP memcache and memcached two pecl library _php tips

Previous attempts to use Memcache, later found memcached support Setmulti method, ready to switch to the memcached library.

(try, in fact, memcache from support for multivalued set, but not on the document, see Changelog seems to be 3.0 starting support, the stable version may not have this feature.) )

As for efficiency, it is not clear how far the gap will be.

Here's an article that says memcached is based on libmemcached and may be better.

Finally, the PHP extension based on Libmemached was released in Pecl.

As a result, there are now two memcache clients on the pecl. One is the memcachethat is developed entirely within the framework of PHP, and one is the use of libmemcached memecached.

function, I have not seen libmemcached, but theoretically, in other languages already popular libmemcached should have more perfect function. and the program performance (memory and CPU usage), it is not easy to say, although pecl::memcache is native implementation, but the use of libmemcached pecl::memached only support Oo interface, and pecl:: Memcache is a combination of OO and non-oo two sets of interfaces, which is a drag on it.

In fact, these are not the most important. Using libmemcached has an obvious advantage, that is, with the memcached server side of the improvement, this LIB will also be followed up immediately. And Pecl::memcache is not necessarily able to follow up on time.

Pecl::memcached, there is also a very commendable place, is flag not in the operation of the time set. But there is a unified setoption (). In this way, it is very worthwhile to go from Pecl::memcache to pecl::memcached. The specific interface can be seen here:http://cvs.php.net/viewvc.cgi/pecl/memcached/memcached-api.php?view=markup

I mentioned in the pecl-dev@ whether I could make a driver-based structure. Like today's MySQL, you can choose to use MYSQLND or libmysql as the underlying engine. But then think about it, I don't really support the use of this architecture for memcached, it's not like MySQL.

MYSQLND is developed as an engine rather than as a new API, allowing a large number of applications to use new engines without modifying database operations. If MYSQLND as a new extension, it faces a difficult choice if it wants to be compatible with previous programs. Because so far, there are 3 official MySQL class sets that use Libmysql and have different external interfaces. MYSQLND can be compatible with MySQL, it cannot be compatible with MYSQLI or PDO. Of course, for programs that use their own abstract database classes, this can be done by rewriting the class or replacing the driver (PHP level) for compatibility. But to think, even with abstract libraries, so many database abstraction libraries in the world, if you want to make it available to all people, how many libraries to add and how many driver.

Memcached the situation is much simpler, the current and official relationship is relatively close only pecl::memcache, and the interface is basically based on the memcached agreement, and Libmemcache the same. They can actually be seen as different driver in an abstract class. So although it is two different sets of clients, but replace it, almost do not need to make any changes, just need to change the place in the class initialization, set/get and so on the flag of these methods can be removed, unless you use a non-OO interface.

In addition, MySQL in communication and data acquisition is also more complex than memcache, ND can do something libmysql can't do. For example, the buffer can be stored directly with PHP's internal Hashtable and Zval, and for example, some structures that are persistent links can be more cached. (These are, for example, just my guess, I didn't go to read the MYSQLND code)

Memcached Manual:

http://cn.php.net/manual/en/book.memcached.php

Memcache Manual:

http://cn.php.net/manual/en/book.memcache.php

Memcached agreement in English and Chinese