I was looking at the php docs on memcache and noticed that instead of doing
$mem->connect(\'localhost\', 11211)
I can do instead
$mem->addServer
Memcache is a distributed cache by design. When you use a pool of servers, the objects are stored on all the servers by a key distribution mechanism that selects a server based on the weight of server and the hash of the key itself.
Now, in a setup on 2 memcache servers, one would go like this:
$memcache = new Memcache;
$memcache->addServer('memcache_host1', 11211);
$memcache->addServer('memcache_host2', 11211);
post these calls, the php process will see the server pool with two servers and distribute the objects evenly to them as the default weights are selected in Memcache::addServer calls. So, a call to Memcache::get or Memcache::set would save an object or retrieve a key value from the right host from the server pool depending on the key.
Memcache::connect, however re-initializes the host pool and assumes that there is only a single host available, and all the objects are stored on that host. This also means, that if you do this:
$memcache = new Memcache;
$memcache->addServer('memcache_host1', 11211);
$memcache->addServer('memcache_host2', 11211);
$memcache->connect('memcache_host1', 11211);
The last call would clear the server pool and all the keys after the the Memcache::connect call will be saved at memcache_host1. So Memcache::connect is ideally used on a single host setup and never with a pool unless the intention is to talk to a specific host in a pool for getting stats, maintenance operations or special caching schemes. More discussion here.
connect and pconnect seem to be more low level calls, that perform a single task without much overhead. addServer OTOH is more high level, managing several servers, retrying when one of them fails, etc. I'm under the impression that the latter relies on the former to do its task.
From the end-user perspective, there's really little advantage in using the lower level function, except perhaps as a small performance improvement (if you know you'll use the connection right away, only have a single memcached server and don't need to keep a persistent connection - or actually wants to reset it for troubleshooting etc - it might be faster to just connect on demand). Only if you need more control over the connection lifecycle (for instance if you're designing your own caching strategy) those functions will be useful.
In other words, the fact that those functions are exposed in the API doesn't imply there will be a common use case for them. Still, it's often better to provide more tools to interact with a system than less, since it encourages platform building.
The difference is actually explained quite well on the docs page for Memcache::addServer
connect() makes a direct connection to a single instance of memcached.
addServer() adds an entry to the server pool that the Memcache extension uses, but does not actually connect until you do something that requires a connection.
When using this method (as opposed to Memcache::connect() and Memcache::pconnect()) the network connection is not established until actually needed. Thus there is no overhead in adding a large number of servers to the pool, even though they might not all be used.
Using a server pool means that if one memcached instance/connection throws a low level error the Memcache extension will automatically connect to another server to make the request.