DOCSP-31596: improve slow operation faq #728
Conversation
There was a problem hiding this comment.
From what I gathered, the major edit was adding an example which I think is helpful!
One of my comments on this PR includes a suggested structure that I think could be helpful to follow in order to reduce the potential assumptions a reader might need to make to understand the problem and solutions. Please feel free to reach out if you have any questions that might be more efficient to answer synchronously!
source/faq.txt
Outdated
| @@ -267,25 +267,40 @@ are some things to check: | |||
| How Can I Prevent a Slow Operation From Delaying Other Operations? | |||
| ------------------------------------------------------------------ | |||
|
|
|||
| You can prevent an operation from slowing down your application by | |||
| specifying the size of the connection pool, which is the cache of | |||
There was a problem hiding this comment.
Issue:
I think "cache" is more of a memory storage/lookup paradigm and is dissimilar from the functionality of a pool, which needs to manage the usage lifecycle of the resources. A cache manages storage and memory allocation.
Suggestion:
- I think it's more accurate to use a description of a connection pool that does not state it is a different paradigm.
- I think "increasing" matches the guidance that follows. If the guidance happens to include "decreasing" in certain cases, this could be "tuning" instead (and that specific advice should be added).
| specifying the size of the connection pool, which is the cache of | |
| increasing the size of the connection pool, which is a group of |
source/faq.txt
Outdated
| (in milliseconds) that requests wait for socket availability. The driver | ||
| does not limit this wait time by default, but to specify a value, you | ||
| can set the ``waitQueueTimeoutMS`` option. You should set this option if | ||
| it is more important to stop long-running operations than it is to |
There was a problem hiding this comment.
Question:
Could you elaborate on how this setting stop long-running operations? I thought it just limits the amount of time an operation waits for the next available connection. If a long-running operation already has the connections it needs, wouldn't it only affect other operations that need connections? And if those operations hit that limit without getting a connection, do they throw exceptions (I think maybe they throw a WaitQueueFull exception or something like that)?
I think it would be helpful to the reader to explain or link to this info since it may not be an appropriate solution depending on their use case.
There was a problem hiding this comment.
I think the original wording here was vague when referencing "long-running" operations. Maybe the original intention was to say that having a lot of operations waiting in the queue can also cause latency? I think it could be useful just to strike this section from this entry.
There was a problem hiding this comment.
@ccho-mongodb this is the response I left for why I removed the section on waitQueueTimeoutMS from the answer. In my research I did not find that this setting stops long running operations, but just clears out the queue when operations have been waiting for too long (as determined by waitQueueTimeoutMS)
source/faq.txt
Outdated
| @@ -267,25 +267,40 @@ are some things to check: | |||
| How Can I Prevent a Slow Operation From Delaying Other Operations? | |||
| ------------------------------------------------------------------ | |||
|
|
|||
| You can prevent an operation from slowing down your application by | |||
There was a problem hiding this comment.
Suggestion:
I think this "preventative" FAQ entry is trickier than others to answer, and maybe the prior entry can benefit from this suggestion too, since it is also a "preventative" one.
Perhaps a better structure for presenting this information could be:
- Help the reader understand whether their use case matches the problem this entry is meant to solve. This is especially important in a preventative as incorrectly assuming it applies to their case could lead to investing time and getting no or negative results.
- I could be wrong, but I think that would include describing how to determine how other operations are suffering delays because one or more slow operations are either taking up all the connections so that the next operation has to wait, or that limited concurrent operations can run because some of the connections are being used by one or more slow operations. This might involve connection monitoring, since it's difficult to tell how many connections any given operation might be taking up.
- Direct the reader to potential solutions to slow operations (e.g. Analyze Performance ) since making the operation quicker is probably a better solution.
- For readers that cannot avoid the situation in which they need to run slow operations and have other operations running on the same connection pool/MongoClient that are getting delayed, provide the advice currently listed:
- increase max connections
- waitQueueTimeout (currently seems to be missing specifics on reason why you might use this)
- Help the reader understand whether it was successful. In this case, maybe that means seeing (through monitoring) that a slow operation doesn't impact the running time of the other operations.
- Optional: direct users to the Developer Forums for specific situations that this doesn't solve.
source/faq.txt
Outdated
| can set the ``waitQueueTimeoutMS`` option. You should set this option if | ||
| it is more important to stop long-running operations than it is to | ||
| complete every operation. The following code sets ``waitQueueTimeoutMS`` | ||
| to ``100`` when creating a new ``MongoClient``: |
There was a problem hiding this comment.
Suggestion:
I think it could to explain what happens when an operation cannot get a connection/socket that it needs by this amount of time so that the reader can understand the tradeoffs.
There was a problem hiding this comment.
Not applicable as I removed the section
There was a problem hiding this comment.
Question: was this section intentionally removed? If so, what were the reasons for removing it?
source/faq.txt
Outdated
| To control the maximum size of a connection pool, you can set the | ||
| ``maxPoolSize`` option in the :ref:`connection options | ||
| <node-connection-options>`. The default value of ``maxPoolSize`` is | ||
| ``100``. If the number of in-use connections to a server reaches | ||
| ``maxPoolSize``, the next request to that server will wait | ||
| until a connection becomes available. To prevent long-running operations | ||
| from slowing down your application, you can increase ``maxPoolSize``. | ||
| until a connection becomes available. The following code sets |
There was a problem hiding this comment.
Question:
From reading this FAQ entry (especially from the waitQueueTimeout section), I thought that the issue was that the client couldn't open enough sockets/connections to send commands, but in the wording of this sentence, it sounds like the server has to wait because there aren't enough connections/sockets to send the response of a command back to the client. Which one is correct or is it both?
Whatever the answer is, could this relationship be clarified in the introductory paragraph?
There was a problem hiding this comment.
changed one of the sentences to reference both possible solutions.
There was a problem hiding this comment.
Per my response below, just removing the second strategy
source/faq.txt
Outdated
| can set the ``waitQueueTimeoutMS`` option. You should set this option if | ||
| it is more important to stop long-running operations than it is to | ||
| complete every operation. The following code sets ``waitQueueTimeoutMS`` | ||
| to ``100`` when creating a new ``MongoClient``: |
There was a problem hiding this comment.
Question: was this section intentionally removed? If so, what were the reasons for removing it?
source/faq.txt
Outdated
| every operation. | ||
| When you use the same ``MongoClient`` instance to run multiple MongoDB | ||
| operations concurrently, a slow operation can cause delays to other | ||
| operations. The slow operation keeps a connection to MongoDB occupied, |
There was a problem hiding this comment.
Suggestion:
I think this should describe the general case since it's not referring to a specific one in the previous sentence.
| operations. The slow operation keeps a connection to MongoDB occupied, | |
| operations. Slow operations keep a connection to MongoDB occupied, |
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes (cherry picked from commit 29e65be)
* DOCSP-31596: imrpove slow op faq * quick fix * CC PR fixes 1 * CC PR fixes 2 * small fixes
Pull Request Info
PR Reviewing Guidelines
JIRA - https://jira.mongodb.org/browse/DOCSP-31596
Staging - https://docs-mongodbcom-staging.corp.mongodb.com/node/docsworker-xlarge/DOCSP-31596-improve-faq/faq/#how-can-i-prevent-a-slow-operation-from-delaying-other-operations-
Self-Review Checklist