Updated the intro to the session pool limit article (#11325)

Co-authored-by: Ivan Blinkov <[email protected]>

Author: anton-bobkov

ydb/docs/en/core/recipes/ydb-sdk/session-pool-limit.md

@@ -1,12 +1,14 @@
 # Setting the session pool size
 
-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.
+{{ ydb-short-name }} creates an [actor](../../concepts/glossary.md#actor) for each session. Consequently, the session pool size of a client affects resource consumption (RAM, CPU) on the server side of {{ ydb-short-name }}.
 
-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.
+For example, if 1000 clients of the same database have 1000 sessions each, then 1000000 [actors](../../concepts/glossary.md#actor) are created on the server side, consuming a significant amount of memory and CPU. If you do not limit the number of sessions on the client side, this may result in a slow cluster that is at risk of failure.
 
-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.
+By default, the {{ ydb-short-name }} SDK sets a limit of 50 sessions when using native drivers. However, no session limit is enforced for third-party libraries, such as Go `database/sql`.
 
-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.
+It’s recommended to set the client session limit to the minimum required for the normal operation of the client application. Keep in mind that sessions are single-threaded on both the server and client sides. For instance, if the application needs to handle 1000 simultaneous (in-flight) requests to {{ ydb-short-name }} based on its estimated load, the session limit should be set to 1000.
+
+It is important to distinguish between estimated RPS (requests per second) and in-flight requests. RPS refers to the total number of requests completed by {{ ydb-short-name }} within one second. For example, if RPS = 10000 and the average latency is 100 ms, a session limit of 1000 is sufficient. This configuration allows each session to perform an average of 10 consecutive requests within the estimated second.
 
 Below are examples of the code for setting the session pool limit in different {{ ydb-short-name }} SDKs.
 

ydb/docs/ru/core/recipes/ydb-sdk/session-pool-limit.md

@@ -1,12 +1,14 @@
 # Установить размер пула сессий
 
-Размер пула сессий на клиенте влияет на потребление ресурсов (память, процессор) на серверной стороне {{ ydb-short-name }}. Простая математика: если `1000` клиентов одной базы данных имеют по `1000` сессий, то на серверной стороне создается `1000000` акторов (воркеров, исполнителей сессий). Если не лимитировать количество сессий на клиенте, то можно получить "задумчивый" кластер в полу-аварийном состоянии.
+{{ ydb-short-name }} создаёт [актор](../../concepts/glossary.md#actor) для каждой сессии. В результате, размер пула сессий на клиенте влияет на потребление ресурсов (память, процессор) на серверной стороне {{ ydb-short-name }}.
 
-По умолчанию в {{ ydb-short-name }} SDK установлен лимит в `50` сессий в случае использования нативных драйверов. При использовании внешних библиотек, например Go database/sql, лимит не установлен.
+Например, если 1000 клиентов одной базы данных открывают по 1000 сессий, то на серверной стороне создаётся 1000000 акторов. Такое количество акторов потребляет значительные объёмы памяти и ресурсов процессора. При отсутствии ограничения на число сессий на клиенте это может привести к медленной работе кластера и его полуаварийному состоянию.
 
-Хорошая рекомендация — устанавливать лимит на количество сессий на клиенте в минимальное-необходимое для штатной работы клиентского приложения. Следует иметь в виду, что сессия однопоточная что на серверной стороне, что на клиентской. Соответственно, если для расчетной нагрузки приложению необходимо выполнять  `1000` одновременных запросов (`inflight`) в {{ ydb-short-name }} — значит следует установить лимит в `1000` сессий.
+По умолчанию в {{ ydb-short-name }} SDK при использовании нативных драйверов установлен лимит в 50 сессий. При использовании сторонних библиотек, например, Go `database/sql`, лимит не задан.
 
-Тут надо отличать расчетный `RPS` (requests per second, запросов в секунду) и `inflight`. В первом случае это общее количество выполненных запросов к {{ ydb-short-name }} за `1` секунду. Например, для `RPS`=`10000` и средним `latency` (задержка исполнения запроса) в `100`мс достаточно установить лимит в `1000` сессий. То есть каждая сессия за расчетную секунду выполнит в среднем `10` последовательных запросов.
+Рекомендуется устанавливать лимит на количество сессий на клиенте в минимально необходимый для штатной работы клиентского приложения. Следует учитывать, что сессия однопоточная как на серверной, так и на клиентской стороне. Соответственно, если для расчётной нагрузки приложению требуется выполнять 1000 одновременных запросов (inflight) в {{ ydb-short-name }}, то лимит следует установить на уровне 1000 сессий.
+
+Важно различать расчётный RPS (requests per second, запросов в секунду) и inflight. В первом случае речь идёт об общем количестве запросов, выполняемых к {{ ydb-short-name }} за 1 секунду. Например, при RPS = 10000 и средней задержке исполнения запроса (latency) в 100 мс достаточно установить лимит в 1000 сессий. Это означает, что каждая сессия за расчётную секунду выполнит в среднем 10 последовательных запросов.
 
 Ниже приведены примеры кода установки лимита на пул сессий в разных {{ ydb-short-name }} SDK.