Оптимальное количество подключений в пуле соединений

Ответ 1

Существует очень простой ответ на этот вопрос:

Количество подключений в пуле соединений должно быть равно числу потоков exec, настроенных в WebLogic.

Обоснование очень просто: если количество подключений меньше количества потоков, некоторые из потоков, возможно, ждут подключения, что делает пул соединений узким местом. Таким образом, он должен быть равен, по крайней мере, числу потоков exec (размер пула потоков).

Ответ 2

Вы действительно имели в виду 200 одновременных пользователей или всего 200 зарегистрированных пользователей? В большинстве случаев пользователь браузера не сможет выполнять более одного запроса страницы в секунду. Таким образом, 200 пользователей переходят на 200 транзакций в секунду. Это довольно большое число для большинства приложений.

Независимо, например, отпустите 200 транзакций в секунду. Скажем, что каждый фронт-терминал (браузер) tx занимает 0,5 секунды, а 0,5 секунды - 0,25, которые хранятся в базе данных. Таким образом, вам понадобится 0,5 * 200 или 100 подключений в пуле WebLogic thead и 0.25 * 200 = 50 соединений в пуле соединений DB.

Чтобы быть в безопасности, я бы установил максимальный размер пула потоков, по крайней мере на 25% больше, чем вы ожидаете, чтобы обеспечить всплески нагрузки. Минимальные значения могут быть малой долей макс, но компромисс заключается в том, что для некоторых пользователей может потребоваться больше времени, потому что необходимо будет создать новое соединение. В этом случае 50 - 100 соединений не так много для БД, чтобы, вероятно, хороший стартовый номер.

Обратите внимание, что для выяснения того, что среднее время реакции на транзакцию, наряду со средним временем запроса БД, вам нужно будет выполнить тест производительности, потому что ваше время при загрузке, вероятно, не будет того, что вы видите с одним пользователем.

Ответ 3

Определение размера пула соединений не является тривиальной вещью. Вам в основном нужно:

• метрики для исследования использования соединения
• механизмы отработки отказа, когда нет доступного соединения

FlexyPool поможет вам определить правильный размер пула соединений.

Вы можете проверить следующие статьи:

• FlexyPool, пул реактивных соединений

• Профессиональный размер пула подключений

• Простое уравнение масштабируемости

Ответ 4

Вы должны просмотреть различные ожидаемые рабочие процессы, чтобы узнать. В идеале ваш пул соединений также будет динамически корректировать количество подключений в реальном времени на основе недавнего использования, так как довольно часто для нагрузки является функцией текущего времени дня в вашей целевой географической области.

Начните с небольшого числа и попытайтесь достичь разумного количества одновременных пользователей, затем сверните его. Я думаю, что, вероятно, вы обнаружите, что ваш механизм объединения соединений не так эффективен в вашей масштабируемости, как в остальном программном обеспечении.

Ответ 5

Пул соединений должен иметь возможность расти и впитываться на основе реальных потребностей. Запишите номера, необходимые для проведения анализа на запущенной системе, либо с помощью протоколирования, либо с помощью наблюдения JMX. Подумайте о настройке предупреждений о сценариях, таких как "обнаруженный пик: больше, чем X новых записей пришлось на Y секунд", "соединение было вне пула более чем на X секунд", что позволит вам уделять внимание проблемам с производительностью до того, как они получат реальные проблемы.

Ответ 6

Это то, что нужно проверять и определять на индивидуальной основе - практически невозможно дать точный ответ на ваши обстоятельства, не будучи близко знакомым с ними.

Ответ 7

Сложно получить данные для этого. Это также зависит от ряда факторов, о которых вы не упоминаете -

• 200 одновременных пользователей, но сколько их активности будет генерировать запросы к базе данных? 10 запросов на загрузку страницы? 1 запрос только при входе в систему? и т.д. и т.д.

• Размер запросов и db, очевидно. Некоторые запросы выполняются в миллисекундах, несколько минут.

Вы можете контролировать mysql для просмотра текущих активных запросов с помощью "show processlist". Это может дать вам лучшее представление о том, сколько активности действительно происходит в db при максимальной нагрузке.

Ответ 8

Исходя из моего опыта работы с финансовыми системами с высокими транзакциями, если вы хотите обрабатывать, например, 1K запросов в секунду, и у вас 32 ЦП, вам нужно иметь 1000/32 открытых опросов соединений с вашей базой данных.

Вот моя формула:

RPS/CPU_COUNT

В большинстве случаев ваш движок базы данных сможет обрабатывать ваши запросы даже в гораздо меньших количествах, но ваши соединения будут в режиме ожидания, если число низкое.

Я думаю, что очень важно упомянуть, что ваша база данных должна быть в состоянии обрабатывать эти транзакции (в зависимости от скорости вашего диска, конфигурации базы данных и мощности сервера).

Удачи.