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

Question

В настоящее время мы используем 4-процессорную Windows box с 8 ГБ оперативной памяти с MySQL 5.x, установленным на той же коробке.Мы используем Weblogic application server для нашего приложения.Мы ориентируемся на 200 одновременных пользователей для нашего приложения (очевидно, не для одного и того же модуля / экрана).Итак, какое оптимальное количество подключений мы должны настроить в пуле подключений (минимальное и максимальное количество) (мы используем weblogic В качестве механизма объединения подключений)?

Answer 1

На этот вопрос очень простой ответ:

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Вы можете ознакомиться со следующими статьями:

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

• Профессиональный Выбор размера пула соединений

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

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

Answer 8

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

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

RPS / CPU_COUNT

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

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

Удачи.