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