diff options
author | alextarazanov <[email protected]> | 2022-10-31 14:31:03 +0300 |
---|---|---|
committer | alextarazanov <[email protected]> | 2022-10-31 14:31:03 +0300 |
commit | 3fe4162400475de2844cc8cd0a9635e1c6878ee7 (patch) | |
tree | 6128d941fda189a41c2fd70b7d615d2fa5af77a0 | |
parent | f7d9221df266d13b4a7036d90d4fe374c7b3e056 (diff) |
[review] [YDB] Check translate database/sql session
-rw-r--r-- | ydb/docs/en/core/reference/ydb-sdk/recipes/session_pool_limit/index.md | 6 |
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. |