According to the PHP SDK 2.0 under Managing Connections, it says
“To close the connection to a bucket, call its disconnect() method.”
When attempting to call the disconnect() method, the following error is returned:
On CouchbaseCluster: “PHP Fatal error: Call to undefined method CouchbaseCluster::disconnect()”
On openBucket: “PHP Fatal error: Call to undefined method CouchbaseBucket::disconnect()”
PHP Version 5.5.22
Couchbase PHP SDK 2.0.5
The main reason I researched how to close a connection is due to the fact each PHP request with a Couchbase call opens a connection and does not close it. After about 4800 concurrent connections the database server crashes.
EDIT: We run an older PHP SDK on our production system (1.x) and this problem does not happen at all. It hovers around 70 concurrent connections with that setup. We’ve spent months migrating our code to the new PHP SDK only for it to bite us in the face in the most critical time that we need it.
To say this is an urgent matter would be putting it mildly.
Thanks for any help
EDIT 2: Added additional error message.
EDIT 3: I just checked the github source and there is no “disconnect” method assigned anywhere. If I knew what I need to write to close a connection within the github source, I’d do it myself and compile it.
Would you kindly provide an example of how you are connecting to your cluster (the full code)? The client is designed to keep connections open and reuse connections from previous scripts to provide faster access to Couchbase from PHP as connecting to Couchbase is a mildly intensive operation. If it is not doing this properly, this would indicate that your connection code may be confusing the matcher which compares your new connection request with previously opened connections.
It’s the only couchbase connection/query in the script. When I comment out the above code, there’s no issue handling thousands of concurrent connections on the HTTP server. But when the above code is executed, the couchbase server gets backed up with thousands of connections according to the couchbase server node panel rendering the couchbase server unresponsive until it eventually crashes.
Do you think it may be a couchbase 3.0.2 issue? Because pointing the above code toward our older Couchbase 2.x server doesn’t result in this problem. Hmm…
UPDATE: To double check if it’s a couchbase server issue, I’ve pointed the script above at the old 2.x couchbase server and it’s handling thousands of concurrent connections without issue. So it appears my original assumption of the PHP SDK having a connection handling issue may be incorrect. Unless it’s an issue specific to the Couchbase 3.0.2 server and the PHP SDK. Apologies, thinking out loud a bit.
So this morning I put the new PHP SDK on our production servers and right away the first issue I saw was that it has 1500+ concurrent connections to the Couchbase 2.x server. On the old PHP SDK 2.0.1 the number of concurrent connections hovered around 100. Is there something I’m missing? Is this an issue in PHP SDK 2.0.5?
Are you aware of what Apache ‘core module’ you are using? worker? prefork? This is important as this changes how many PHP instances are created.
P.S. For performance reasons we keep our libcouchbase instances alive as long as possible, even across requests. This means in the case of having many apache workers running at once, each with mod_php loaded, I would expect to see lots of established connections as you are seeing.
I suspect that this is the cause of the high connection count:
In this case, the high connection count should not be anything to worry about and is in fact a good, as it represents that your clients are staying online and reducing the ‘spin up time’ of your scripts by avoiding the multiple round-trips required to bootstrap and connect to Couchbase Server.
So we moved from IIS 7, PHP 5.5, Couchbase 2.0.1 to Apache 2.0, PHP 5.5, Couchbase 2.0.5
On our old system, we hovered around 140 couchbase connections. New system we get thousands of connections, to the point that the couchbase server crashes. This is where we’re at and are frustrated. We’ve eliminated MySQL from our code and the issue still happens.
EDIT: Just ran yum update on PHP, now at PHP 5.5.23 … curious if maybe it’s just a PHP issue not playing nice? Time will tell. Will keep you updated.
Well, it worked fine until we got a traffic spike. It then locked the couchbase server up. Mind you this couchbase server worked fine on our old system and old SDK’s. The only fix at the moment is to restart the apache service, but that only lasts about 15 minutes before couchbase crashes again. I’m scratching my head right now.
Edit: couchbase server crashed so hard that I had to physically reboot the server it’s running on, restarting the service didn’t do anything