fix text

fix text

2 files changed, 2 insertions, 2 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 e66ab938cd..ec1a9ce277 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,7 +3,7 @@
 {% 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, `100000` 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.
+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`.
 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.
diff --git a/ydb/docs/ru/core/reference/ydb-sdk/recipes/session_pool_limit/index.md b/ydb/docs/ru/core/reference/ydb-sdk/recipes/session_pool_limit/index.md
index b3ef4339a2..b97cabcb5d 100644
--- a/ydb/docs/ru/core/reference/ydb-sdk/recipes/session_pool_limit/index.md
+++ b/ydb/docs/ru/core/reference/ydb-sdk/recipes/session_pool_limit/index.md
@@ -3,7 +3,7 @@
 {% include [work in progress message](../_includes/addition.md) %}
 
 Размер пула сессий на клиенте влияет на потребление ресурсов (память, процессор) на серверной стороне {{ ydb-short-name }}.
-Простая математика: если `1000` клиентов одной базы данных имеют по `1000` сессий, то на серверной стороне создается `100000` акторов (воркеров, исполнителей сессий). Если не лимитировать количество сессий на клиенте, то можно получить "задумчивый" кластер в полу-аварийном состоянии.
+Простая математика: если `1000` клиентов одной базы данных имеют по `1000` сессий, то на серверной стороне создается `1000000` акторов (воркеров, исполнителей сессий). Если не лимитировать количество сессий на клиенте, то можно получить "задумчивый" кластер в полу-аварийном состоянии.
 По умолчанию в {{ ydb-short-name }} SDK установлен лимит в `50` сессий.
 Хорошая рекомендация — устанавливать лимит на количество сессий на клиенте в минимальное-необходимое для штатной работы клиентского приложения. Следует иметь в виду, что сессия однопоточная что на серверной стороне, что на клиентской. Соответственно, если для расчетной нагрузки приложению необходимо выполнять  `1000` одновременных запросов (`inflight`) в {{ ydb-short-name }} — значит следует установить лимит в `1000` сессий.
 Тут надо отличать расчетный `RPS` (requests per second, запросов в секунду) и `inflight`. В первом случае это общее количество выполненных запросов к {{ ydb-short-name }} за `1` секунду. Например, для `RPS`=`10000` и средним `latency` (задержка исполнения запроса) в `100`мс достаточно установить лимит в `1000` сессий. То есть каждая сессия за расчетную секунду выполнит в среднем `10` последовательных запросов.