PHP SDK connection pooling
Does the PHP SDK support connection pooling? I have similar scenario as http://www.couchbase.com/forums/thread/connection-pooling-couchbase-sdk-... but for the PHP SDK. My guess is it does not due to the nature of PHP.
Example: I have 2 node couchbase v2 server cluster. I have 50 servers, each running PHP-FPM (ave 250 children/per) each using the SDK persistent connection. That's 12500 connections - and more when I scale up my servers or fpm children.
Today I solve this problem with the stand alone moxi server (it manages the connection pool on each server).
If PHP SDK does support pooling, can someone go into a bit of detail how it works - and how it can be configured? ALso interested if there are any recommendations/docs on the # of persistent socket connections couchbase server v2.0 can handle.
thanks
Ok thanks. This is exactly how MySQL persistent connections work in PHP.
Problem with this is you are not able to control the # of connections (like you can in client stand alone moxi). Instead, you are at the mercy of the # of PHP child threads. In FPM (or apache for that matter) you may not need as many connections to couchbase as you have child processes.
Example (nginx+php-fpm):
If I have configured FPM to scale up to 250 child threads (to handle 250 concurrent PHP requests) it means that I will have up to 250 persistent (and re-usable as you state) connections to couchbase server.
If 10k connections is the soft threshold, that is 40 server instances w/ the above example - very reachable in a virtual / auto scaling environment like AWS.
In the MySQL case, this is a pretty big deal - so you get around it with using connection pooling (which you cant do in PHP - can in java) or you don't use persistent connections.
For couchbase, IMO, client side stand alone moxi is the solution. You can tune it to only have X persistent connections to your couchbase server (downstream_conn_max) and Y threads (-t Y); drastically cutting down the # of clients connecting to the server (and eating up the finite resource). The little higher response time, and extra app maintenance is worth saving the finite resource. I find that 16 downstream connections and 8 threads work excellent for my 250 FPM child setup (for my workload of course). That's 15x connection savings.
This example above is no different if you use apache - its just your child thread is tied up if your serving a PHP file or a static file (if your using mod_php).
With all this being said, I don't see this as a problem, I just wanted to understand how things work so I could evaluate the work needed and benefit in going to v2 and using the SDK.
Only question left would be are there things you can do in the SDK that you can not do through stand alone moxi. If answer is yes - can you use the SDK to connect to stand alone moxi to leverage the feature? If there are things you can do only with SDK->Couchbase server - then you'll have to evaluate the connection problem vs the feature set you gain.
thanks for your time. Hopefully this helps someone else too.
The PHP client library currently implements what is commonly referred to in PHP as "persistent connections" (though arguably this isn't really a proper definition).
What this means is that if you pass enough arguments and the last one is true when instantiating the client, a subsequent call to the constructor will look for an existing instantiated version of the object, and use it if it exists. If it doesn't exist, it will be created and then used.
In effect this means you have one set of connections to the cluster for each process, which is the best thing to do with PHP. In effect, it's a connection pool, but an association of one set of connections to each process rather than having processes coordinate access to acquiring/releasing a set of connections from a common pool.
The recommendation is pretty simple: just pass "true" as the last parameter as documented in the constructor. The only place this could possibly be a problem is if you have greater than 10k client processes-- and then we can solve things with some additional tuneables. We don't have specific confirmation from the php-fpm project itself, but looking at code seems to confirm it supports this approach in common with running under Apache.
I hope that helps!