tomcat - соотношение между HTTP Connector maxThreads / acceptCount и пулом JDBC maxActive

Есть ли какое-то общепринятое соотношение между

  • HTTP-коннектор maxThreads (максимальное количество HTTP-потоков, обрабатывающих запросы пользователей),
  • HTTP-коннектор acceptCount (максимальная длина очереди для входящих запросов на соединение, когда используются все возможные потоки обработки запросов)
  • Свойства конфигурации пула БД maxActive (максимальное количество подключений к БД в пуле)

когда дело доходит до базового веб-приложения, использующего tomcat с интенсивным использованием базы данных?

Я имею в виду, что, например, почти каждое соединение HTTP-запроса интенсивно использует базу данных. Итак, когда у нас, например, гораздо меньше настроенного пула DP maxActive (например, 100), в то время как HTTP-коннектор maxThreads (например, 200) в два раза больше. Тогда может появиться возможность использовать одно и то же соединение с БД для совместного использования HTTP-соединениями. А это может привести к интенсивному использованию БД / блокировке соединений с БД.

Я знаю, что конфигурация веб-HTTP-запросов в большинстве случаев не имеет отношения к конфигурации пула базы данных, но есть ли общие случаи / практики для соотношения свойств (maxThreads / acceptCount maxActive)? Например. является распространенной практикой, чтобы HTTP maxThreads был больше, чем DB maxActive (но думать, что на 100% больше - это слишком много, как в нашем примере - может быть, скажем, на 20 или 50% больше?) и допустим, у нас есть accpetCount с большим значением , чтобы поставить в очередь HTTP-запросы к тому моменту, когда другие HTTP-запросы будут обработаны приложением?

Здесь есть аналогичный вопрос: Tomcat - Настройка maxThreads и acceptCount в соединителе Http но точного ответа на него нет


java tomcat httpconnection jdbc-pool
person Simeon Angelov    schedule 06.11.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Для начала несколько уточнений:

  • Соединения JDBC не распределяются между потоками, чтобы не нарушить требование изоляции. Если пул исчерпан, запрос будет ждать в очереди, пока не будут назначены соединения или не истечет время ожидания.
  • Запросы обслуживаются по мере их поступления до значения maxThreads, любые дополнительные запросы помещаются в очередь до значения acceptCount.

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

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

Тем не менее, нет особого смысла в поиске соотношения между этими значениями, поскольку maxActive наложит ограничение. maxThreads> = maxActive - очевидное практическое правило.

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

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

Динамика пула относится к минимуму простаивающих соединений / потоков, как долго простаивают, сколько новых записей в пуле создается одновременно и т. Д.

Надеюсь это поможет!

Документы по HTTP-коннектору Tomcat 7.

person LMC    schedule 06.11.2018
comment
Спасибо, Луис, за подробный ответ. Следуя вашему мнению, во избежание того, чтобы http-потоки ожидали подключения к БД (мы предполагаем, что http-запросы пользователей интенсивно используют БД), возможно, стоит сделать оба значения maxActive и maxThreads более похожими по смыслу значения maxThreads на быть не намного больше, чем значение maxActive, поскольку в этом случае мы могли бы столкнуться с некоторыми соединениями с задержкой внешнего интерфейса (поскольку потоки внешнего интерфейса http будут ждать доступного соединения с базой данных)? Например. maxActive = 100 и maxThreads = 130 или аналогичные, но не удваивают / утраивают количество maxThreads - person Simeon Angelov; 07.11.2018
comment
По умолчанию maxThreads = 200, почему бы не оставить все как есть? Уменьшение значения не улучшит производительность. С другой стороны, зависание соединения, вероятно, вызвано тем, что приложение не отвечает вовремя. Возможно, maxActive = 100 недостаточно для вашей нагрузки. Настройка производительности - это поиск узких мест и их устранение, а не установка ограничений. - person LMC; 07.11.2018
comment
да, но в нашем случае потоки http ждут подключения к базе данных из пула, когда пул базы данных заполнен - ​​все подключения базы данных используются другими потоками http. Создание обоих свойств с одинаковыми значениями может потенциально избежать остановки соединений и горизонтального масштабирования самого приложения - количества экземпляров. К сожалению, увеличение количества подключений к базе данных на экземпляр будет ограничивать с другой стороны ограничения DB для подключений к базе данных. экземпляр БД. В конце - комбинация H scale up / maxThreads / maxActive - тесты diff perf покажут лучшую комбинацию - person Simeon Angelov; 08.11.2018
comment
Итак, если мне нужно соединение jdbc для любого http-запроса, настройка maxThreads == maxActive подойдет? А если у меня есть какие-то другие потоки (cron или что-то еще), может быть maxThreads ‹maxActive из 5 подключений? Я думаю, что конфигурация по умолчанию - это другой способ из-за запросов статических файлов, которые обычно не нуждаются в jdbc. - person Mr_Thorynque; 13.01.2021
comment
maxActive должен каким-то образом следовать тому, что диктует maxThreads, и это зависит от нагрузки HTTP-запросов. Оба должны обеспечивать максимальную стабильную нагрузку на ваше приложение плюс некоторые разумные накладные расходы. maxThreads < maxActive - это не обычный случай, я думаю, пул jdbc в этом случае может быть слишком большим. - person LMC; 13.01.2021