Ответ
Стандартное значение — 200 одновременных запросов, определяемое параметром maxThreads в конфигурации Connector.
Настройка в server.xml:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
maxThreads="500"
redirectPort="8443" />Факторы, влияющие на производительность:
- Аппаратные ресурсы: CPU, память, сеть.
- Размер пула потоков (
maxThreads): определяет реальный параллелизм. - Длина очереди (
acceptCount): количество запросов, которые могут ждать обработки, когда все потоки заняты. - Характер запросов: время выполнения и использование keep-alive соединений.
Рекомендации: Для высоконагруженных систем увеличивайте maxThreads (например, до 500-1000) и настраивайте acceptCount, мониторя использование ресурсов.
Ответ 18+ 🔞
Да ты посмотри, что они тут понаписали про эти твои 200 одновременных запросов! «Стандартное значение», блядь. Ну стандартное, как моё стандартное утреннее состояние — с похмелья и на автопилоте. Это они про maxThreads в коннекторе, который, если его не трогать, как раз и будет 200.
То есть представь: твой Tomcat, такой важный, сидит, ждёт. И к нему лезут, лезут запросы. А он их берёт и кидает в обработку, но одновременно — только 200 штук. Остальные, блядь, в очередь становятся, как за дефицитным пивом в девяностые. И если очередь переполнится — ну, пиши пропало, клиенту придёт отлуп.
А чтобы этого не было, надо в конфиге поковыряться. Вот смотри, в этом самом server.xml:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
maxThreads="500"
redirectPort="8443" />Видишь? maxThreads="500". Вот мы и увеличили лимит, теперь не 200, а 500 потоков могут одновременно ебашить. Но это, конечно, не волшебная таблетка, ёпта.
Потому что дальше начинается самое интересное. На производительность влияет овердохуища всего:
- Железо твоё. Если у тебя процессор — хуй с горы, а оперативки — на один чих, то хоть тысячу потоков настрой — они просто будут друг другу мешать, как пьяные мартышки в тесной клетке.
- Сам этот
maxThreads. Это ж не абстрактная цифра, а реальные потоки, которые будут жрать память и процессорное время. Поставишь слишком много — система начнёт больше времени на переключение контекста тратить, чем на работу. Чистый пиздец. - Очередь, ёб твою мать (
acceptCount). Это сколько запросов могут постоять в приёмной, пока все потоки заняты. Как в поликлинике талоны берут. Настроишь мало — будут отказывать сразу. Настроишь много — запросы будут ждать до второго пришествия, а пользователь уже уйдёт. - И что за запросы-то? Если они быстрые, как укол в жопу — одно дело. А если каждый запрос — это тяжёлая аналитика на пять минут, то тут хоть обосрись потоками, очередь всё равно будет.
Так что, чувак, рекомендации ихние — они такие... общие. «Увеличивайте maxThreads до 500-1000». Ага, щас. А память кто даст? Мониторь, говорят, ресурсы. Абсолютно верно! Сначала смотри, как твоё приложение дышит, сколько памяти жрёт на поток, сколько CPU свободного. А потом уже крути ручки. И acceptCount не забудь подкрутить, чтобы не получилось, как у того Герасима — либо всё, либо ничего.