@@ -117,30 +117,30 @@ worker process. This process is described in more detail in the
117
117
118
118
Each libmongoc client maintains its own connections to the MongoDB deployment
119
119
and a view of its topology. When a persistent libmongoc client is reused, the
120
- PHP driver is able to avoid the overhead of establishing new connections and
120
+ PHP driver can avoid the overhead of establishing new connections and
121
121
rediscovering the topology. This approach generally improves performance and is
122
122
therefore the driver's default behavior.
123
123
124
- Persistent libmongoc clients are not destroyed until the PHP worker process
124
+ Persistent libmongoc clients are not freed until the PHP worker process
125
125
terminates. This means that connections to a MongoDB deployment may remain open
126
126
long after a ``MongoDB\Driver\Manager`` object goes out of scope. While this is
127
127
typically not an issue for applications that connect to one MongoDB deployment,
128
128
it could be problematic in some situations. Consider the following cases:
129
129
130
- - PHP-FPM is configured with ``pm.max_requests=0`` (i.e. workers never respawn)
131
- and a PHP application is deployed many times with small changes to its MongoDB
132
- connection string and/ or options. This could lead to an accumulation of
133
- libmongoc client objects within each worker process.
130
+ - PHP-FPM is configured with ``pm.max_requests=0`` (workers never respawn) and a
131
+ PHP application is deployed many times with small changes to its MongoDB
132
+ connection string or options. This could lead to an accumulation of libmongoc
133
+ client objects within each worker process.
134
134
- An application occasionally connects to a separate MongoDB deployment in some
135
135
backend component where request latency is not paramount.
136
136
137
137
In the first case, restarting PHP-FPM as part of the application deployment
138
- would allow the application to relinquish any unused libmongoc clients and still
139
- utilize a persistent client for the latest connection string.
138
+ allows the application to relinquish any unused libmongoc clients and still use
139
+ a persistent client for the latest connection string.
140
140
141
141
The second case warrants a different solution. Specifying ``true`` for the
142
142
``disableClientPersistence`` driver option will instruct the PHP driver to
143
- create a new libmongoc client and ensure it is destroyed when the corresponding
143
+ create a new libmongoc client and ensure it is freed when the corresponding
144
144
``MongoDB\Driver\Manager`` goes out of scope.
145
145
146
146
.. code-block:: php
@@ -153,9 +153,9 @@ create a new libmongoc client and ensure it is destroyed when the corresponding
153
153
driverOptions: ['disableClientPersistence' => true],
154
154
);
155
155
156
- The ``disableClientPersistence`` driver option should be used sparingly, as
157
- opting out of client persistence means that additional time will be required to
158
- establish connections to the MongoDB deployment and discover its topology.
156
+ Use the ``disableClientPersistence`` driver option sparingly, as opting out of
157
+ client persistence will require more time to establish connections to the
158
+ MongoDB deployment and discover its topology.
159
159
160
160
161
161
Server Selection Failures
0 commit comments