Skip to content

Commit 71f110a

Browse files
jmikolarustagir
authored andcommitted
Address vale lint checks on word usage
(cherry picked from commit edc759a)
1 parent 64fa7ff commit 71f110a

File tree

1 file changed

+12
-12
lines changed

1 file changed

+12
-12
lines changed

source/faq.txt

Lines changed: 12 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -117,30 +117,30 @@ worker process. This process is described in more detail in the
117117

118118
Each libmongoc client maintains its own connections to the MongoDB deployment
119119
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
121121
rediscovering the topology. This approach generally improves performance and is
122122
therefore the driver's default behavior.
123123

124-
Persistent libmongoc clients are not destroyed until the PHP worker process
124+
Persistent libmongoc clients are not freed until the PHP worker process
125125
terminates. This means that connections to a MongoDB deployment may remain open
126126
long after a ``MongoDB\Driver\Manager`` object goes out of scope. While this is
127127
typically not an issue for applications that connect to one MongoDB deployment,
128128
it could be problematic in some situations. Consider the following cases:
129129

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.
134134
- An application occasionally connects to a separate MongoDB deployment in some
135135
backend component where request latency is not paramount.
136136

137137
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.
140140

141141
The second case warrants a different solution. Specifying ``true`` for the
142142
``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
144144
``MongoDB\Driver\Manager`` goes out of scope.
145145

146146
.. code-block:: php
@@ -153,9 +153,9 @@ create a new libmongoc client and ensure it is destroyed when the corresponding
153153
driverOptions: ['disableClientPersistence' => true],
154154
);
155155

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.
159159

160160

161161
Server Selection Failures

0 commit comments

Comments
 (0)