tomcat - соотношение между HTTP Connector maxThreads / acceptCount и пулом JDBC maxActive - PullRequest
Новая
       38

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

0 голосов
/ 06 ноября 2018

Есть ли что-то в качестве принятого здравого смысла соотношения между

  • HTTP Connector maxThreads (макс. HTTP-потоки, обрабатывающие запросы пользователей),
  • HTTP Connector 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 , но без более точного ответа на него

1 Ответ

0 голосов
/ 06 ноября 2018

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

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

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

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

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

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

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

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

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

Документы по соединителю HTTP Tomcat 7 .

...