The Connection Pooledit
The connection pool is an object inside the client that is responsible for maintaining the current list of nodes. Theoretically, nodes are either dead or alive.
However, in the real world, things are never so clear. Nodes are sometimes in a gray-zone of "probably dead but not confirmed", "timed-out but unclear why" or "recently dead but now alive".
The connection pool’s job is to manage this set of unruly connections and try to provide the best behavior to the client. There are several connection pool implementations that you can choose from:
staticNoPingConnectionPool (default)edit
This connection pool maintains a static list of hosts, which are assumed to be alive when the client initializes. If
a node fails a request, it is marked as dead for 60 seconds and the next node is tried. After 60 seconds, the node
is revived and put back into rotation. Each additional failed request will cause the dead timeout to increase exponentially.
A successful request will reset the "failed ping timeout" counter.
staticConnectionPooledit
Identical to the staticNoPingConnectionPool, except it pings nodes before they are used to determine if they are alive.
This may be useful for long-running scripts, but tends to be additional overhead that is unescessary for average PHP scripts.
sniffingConnectionPooledit
Unlike the two previous static connection pools, this one is dynamic. The user provides a seed list of hosts, which the client uses to "sniff" and discover the rest of the cluster. It achieves this through the Cluster State API. As new nodes are added or removed from the cluster, the client will update it’s pool of active connections.
Which connection pool to choose? PHP and connection poolingedit
At first blush, the sniffingConnectionPool implementation seems superior. For many languages, it is. In PHP, the conversation is a bit more nuanced.
Because PHP is a share-nothing architecture, there is no way to maintain a connection pool across script instances. This means that every script is responsible for creating, maintaining, and destroying connections on every instantiation.
Sniffing is a relatively lightweight operation but it may be considered a non-negligible overhead for certain PHP applications.
The average PHP script will likely load the client, execute a few queries and then close. Imagine this script being called 1000 times per second: the sniffing connection pool will perform the sniffing and pinging process 1000 times per second.
In reality, if your script only executes a few queries, the sniffing concept is too robust. It tends to be more useful in long-lived processes which potentially "out-live" a static list.
For this reason the default connection pool is currently the staticNoPingConnectionPool. You can, of course, change this default - but we strongly recommend you load test and verify that it does not negatively impact your performance.
Changing the Connection Pooledit
Changing the connection pool is very simple: instantiate the client with your chosen connection pool implementation:
$params['connectionPoolClass'] = '\Elasticsearch\ConnectionPool\SniffingConnectionPool'; $client = new Elasticsearch\Client($params);