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.
$cbConn = new CouchbaseCluster("remote_database_ip");
$cbQuery = CouchbaseViewQuery::from("viewVideoKey", "getKey")->key("videoStreamToken");
$rawResult = $cbRes->query($cbQuery);
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.
Still stuck in the water with this connection issue.
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?
Any help or insight is appreciated
It’s Friday night and we’re fucked. Nobody seems to have any answers or offer any help with what’s going on.
I have referred this issue to a colleague of mine who is taking a look. We will get back to you as soon as possible!
Something that will help us however is if you could tell us if your switch from 2.0.1 to 2.0.5 included an upgrade to your libcouchbase version?
Did you upgrade your libcouchbase, and thats what you upgraded to, or was it that version of libcouchbase both for 2.0.5 and 2.0.1.
We installed it on a fresh server a few weeks back.
Just attempted to update the existing libcouchbase and came up with these conflicts: http://prntscr.com/6nc8sc
Edit: I’m an idiot haha, had to remove the libcouchbase2 via yum. Did that just now and installed the 2.4.8 libcouchbase. Let’s see how this does.
Looks like same issue is happening with libcouchbase 2.4.8: http://prntscr.com/6ncgr4
It jumps to 4000+ connections when it should be hovering around 140 connections.
Couchbase PHP SDK 2.0.5
How is your PHP configured? Are you using fastcgi, or mod_php, or some other kind of configuration, additionally, what underlying server is being used? IIS? Nginx? Apache?
I sent you a private message with a link to a phpinfo page on our server. Hopefully that gives you needed info.
Thanks again for your help with this.
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.
Using prefork in Apache.
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.
So far so good. I updated PHP and changed the Apache settings from 10000 to 500. Hopefully this does it! Been hovering around 180 couchbase connections, which is a good sign.
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