summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authoralextarazanov <[email protected]>2022-10-31 14:31:03 +0300
committeralextarazanov <[email protected]>2022-10-31 14:31:03 +0300
commit3fe4162400475de2844cc8cd0a9635e1c6878ee7 (patch)
tree6128d941fda189a41c2fd70b7d615d2fa5af77a0
parentf7d9221df266d13b4a7036d90d4fe374c7b3e056 (diff)
[review] [YDB] Check translate database/sql session
-rw-r--r--ydb/docs/en/core/reference/ydb-sdk/recipes/session_pool_limit/index.md6
1 files changed, 5 insertions, 1 deletions
diff --git a/ydb/docs/en/core/reference/ydb-sdk/recipes/session_pool_limit/index.md b/ydb/docs/en/core/reference/ydb-sdk/recipes/session_pool_limit/index.md
index ec1a9ce2775..7cf9390b2d6 100644
--- a/ydb/docs/en/core/reference/ydb-sdk/recipes/session_pool_limit/index.md
+++ b/ydb/docs/en/core/reference/ydb-sdk/recipes/session_pool_limit/index.md
@@ -3,9 +3,13 @@
{% include [work in progress message](../_includes/addition.md) %}
The client's session pool size affects resource consumption (RAM, CPU) on the server side of {{ ydb-short-name }}.
+
Simple math: if `1000` clients of the same DB have `1000` sessions each, `1000000` actors (workers, session performers) are created on the server side. If you don't limit the number of sessions on the client, this may result in a slow cluster that is close to a failure.
-By default, the {{ ydb-short-name }} SDK limits the number of sessions to `50`.
+
+By default, the {{ ydb-short-name }} SDK has a limit of `50` sessions when using native drivers. There is no limit for third-party libraries, such as Go database/sql.
+
A good recommendation is to set the limit on the number of client sessions to the minimum required for the normal operation of the client app. Keep in mind that sessions are single-threaded both on the server and client side. So if the application needs to make `1000` simultaneous (`inflight`) requests to {{ ydb-short-name }} for its estimated load, the limit should be set to `1000` sessions.
+
Here it's necessary to distinguish between the estimated `RPS` (requests per second) and `inflight`. In the first case, this is the total number of requests to {{ ydb-short-name }} completed within `1` second. For example, if `RPS`=`10000` and the average `latency` is `100`ms, it's sufficient to set the session limit to `1000`. This means that each session will perform an average of `10` consecutive requests for the estimated second.
Below are examples of the code for setting the session pool limit in different {{ ydb-short-name }} SDKs.