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, но без более точного ответа на него
Ответы 1
Для начала несколько уточнений:
- Соединения JDBC не разделяются между потоками, чтобы избежать нарушения требований изоляции. Если пул исчерпан, запрос будет ждать в очереди, пока не будут назначены соединения или не истечет время ожидания.
- Запросы обслуживаются по мере их поступления до значения maxThreads, любые дополнительные запросы помещаются в очередь до значения acceptCount.
acceptCount: The maximum queue length for incoming connection requests when all possible request processing threads are in use.
- maxActive является узким местом в вашем примере, поэтому запросы, превышающие это число, будут ожидать подключения к базе данных. Точнее, узким местом является пул соединений с базой данных. Вы не получите застопоренных соединений с базами данных, а скорее потоки, ожидающие подключения из пула.
Тем не менее, нет особого смысла в поиске соотношения между этими значениями, поскольку maxActive наложит ограничение. maxThreads> = maxActive - очевидное практическое правило.
maxThreads никогда не будет достигнут, если это не указано в нагрузке вашего приложения, но тогда ваш пул базы данных должен быть в состоянии справиться с этой нагрузкой, иначе ваше приложение выйдет из строя.
Настройка производительности в этом случае больше связана с настройкой пула соединений с базой данных и динамикой пула потоков, чем с установкой ограничений. После того, как пределы достигнуты, делать нечего: либо найти код, вызывающий замедление, либо увеличить масштаб.
Динамика пула относится к минимуму простаивающих соединений / потоков, как долго простаивают, сколько новых записей в пуле создается одновременно и т. д.
Надеюсь это поможет!
Документация по HTTP-коннектору Tomcat 7.
По умолчанию maxThreads = 200, почему бы не оставить все как есть? Уменьшение значения не улучшит производительность. С другой стороны, зависание соединения, вероятно, вызвано тем, что приложение не отвечает вовремя. Возможно, maxActive = 100 недостаточно для вашей нагрузки. Настройка производительности - это поиск узких мест и их устранение, а не установка ограничений.
да, но в нашем случае потоки http ждут подключения к базе данных из пула, когда пул базы данных заполнен - все подключения базы данных используются другими потоками http. Создание обоих свойств с похожими значениями может потенциально избежать остановки соединений и горизонтального масштабирования самого приложения - количества экземпляров. экземпляр БД. В конце - комбинация H scale up / maxThreads / maxActive - тесты diff perf покажут лучшую комбинацию
Итак, если мне нужно соединение jdbc для любого http-запроса, настройка maxThreads == maxActive хороша? И если у меня есть другие потоки (cron или что-то еще), может быть maxThreads <maxActive из 5 подключений? Я думаю, что конфигурация по умолчанию - это другой способ из-за статических запросов файлов, которые обычно не нуждаются в jdbc.
maxActive должен каким-то образом следовать тому, что диктует maxThreads, и это зависит от нагрузки HTTP-запросов. Оба должны обеспечивать максимальную стабильную нагрузку на ваше приложение плюс некоторые разумные накладные расходы. maxThreads < maxActive - это не обычный случай, я думаю, пул jdbc в этом случае может быть слишком большим.
Спасибо, Луис, за подробный ответ. Следуя вашему мнению, чтобы избежать HTTP-потоков, ожидающих подключения к БД (мы предполагаем, что HTTP-запросы пользователей интенсивно используют БД), возможно, стоит сделать оба значения maxActive и maxThreads более похожими по смыслу значение maxThreads на быть не намного больше, чем значение maxActive, поскольку в этом случае мы могли бы столкнуться с некоторыми задержками соединений внешнего интерфейса (поскольку потоки внешнего интерфейса http будут ждать доступного соединения с базой данных)? Например. maxActive = 100 и maxThreads = 130 или аналогичные, но не удваивают / утраивают количество maxThreads