Connection Pooling (version 1.2.0-1.2.12
*only*)
Connection Pooling (version 1.2.0-1.2.12
*only*)
Connection Pooling (version 1.2.0-1.2.12
*only*)
Note:
This section is no longer relevant as of the 1.3.0
release of the driver and only serves as a historical information
on how the pooling used to work.The latest versions of the driver have no concept
of pooling anymore and will maintain only one connection per
process, for each connection type (ReplicaSet/standalone/mongos),
for each credentials combination.
Creating connections is one of the most heavyweight
things that the driver does. It can take hundreds of milliseconds
to set up a connection correctly, even on a fast network. Thus, the
driver tries to minimize the number of new connections created by
reusing connections from a pool.
When a user creates a new instance of MongoClient, all
necessary connections will be taken from their pools (replica sets
may require multiple connections, one for each member of the set).
When the MongoClient instance goes out of scope, the
connections will be returned to the pool. When the PHP process
exits, all connections in the pools will be closed.
“Why do I have so many open connections?”
Connection pools can generate a large number of
connections. This is expected and, using a little arithmetic, you
can figure out how many connections will be created. There are
three factors in determining the total number of connections:
-
connections_per_pool
Each connection pool will create, by default, an
unlimited number of connections. One might assume that this is a
problem: if it can create an unlimited number of connections,
couldn’t it create thousands and the server would run out of file
descriptors? In practice, this is unlikely, as unused connections
are returned to the pool to be used later, so future connections
will use the same connection instead of creating a new one. Unless
you create thousands of connections at once without letting any go
out of scope, the number of connections open should stay at a
reasonable number.You can see how many connections you have in a pool
using the MongoPool::info() function. Add up the
“in use” and “in pool” fields for a given server. That is the total
number of connections for that pool. -
pools_per_process
Each MongoDB server address you’re connecting to
gets its own connection pool. For example, if your local hostname
is “example.net”, connecting to “example.net:27017”,
“localhost:27017”, and “/tmp/mongodb-27017.sock” will create three
connection pools. You can see how many connection pools you have
open using MongoPool::info(). -
processes
Each PHP process has a separate set of pools.
PHP-FPM and Apache generally create between 6 and a couple of dozen
PHP worker children. Check your settings to see what the max number
of PHP processes is that can be spawned.If you are using PHP-FPM, estimating the number of
connections can be tricky because it will spawn more PHP-FPM
workers under heavy load. To be on the safe side, look at the
max_children parameter or add up spare_servers +
start_servers (choose whichever number is higher). That
will indicate how many PHP processes (i.e. sets of pools) you
should plan for.
The three variables above can be multiplied
together to give the max number of connections expected:
connections_per_pool * pools_per_process *
processes. Note that connections_per_pool can be
different for different pools, so connections_per_pool
should be the max.
For example, suppose we’re getting 30 connections
per pool, 10 pools per PHP process, and 128 PHP processes. Then we
can expect 38400 connections from this machine. Thus, we should set
this machine’s file descriptor limit to be high enough to handle
all of these connections or it may run out of file descriptors.
See MongoPool for more information on connection
pooling.