Что определяет количество одновременных соединений

Ответ 1

Интересный вопрос. Если мы обойдем все атрибуты, определяющие производительность, в конечном итоге это сводится к тому, сколько работы вы делаете в сервлете или сколько времени требуется, если у него самые высокие значения ввода-вывода, процессора и памяти. Теперь давайте переместимся вниз с вашим списком с учетом вышеупомянутого утверждения: -

Количество HTTP-соединений, которые сервер может разрешить для каждого порта

limit для файловых дескрипторов, но это снова запускается по тому, сколько времени сервлет выполняет полный запрос или сколько времени требуется от первого байта запроса чтобы завершить отправку всего ответа. Поскольку, если требуется всего 1 мс, и вы используете Netty и постоянное соединение, вы можете достичь действительно высокого уровня → 6000.

Количество сервлетов в пуле

Теоретически → 6000. Но сколько потоков обрабатывает ваши запросы? Есть ли пул потоков, который записывает ваши запросы? Таким образом, вы хотите увеличить потоки, но сколько позволяет сказать 2000 одновременных потоков. Неужели ваш процессор плохо себя ведет с переключением контекста? Связано ли это с I/O? если да, это имеет смысл для контекстного коммутатора, но тогда вы будете бить эти сетевые ограничения, потому что много потоков ожидает сетевого ввода-вывода, поэтому в конечном счете, сколько времени вы потратили на часть работы.

БД

Если это оракул, благослови вас с помощью управления подключением, вам определенно нужен строгий мониторинг здесь. Теперь это еще один ограничивающий фактор и может рассматриваться как просто еще один блокирующий ввод-вывод. По определению I/O, задержка/пропускная способность важна и становится узким местом, когда она становится больше, чем самая маленькая часть работы.

Итак, наконец, вам нужно разбить следующие или более атрибуты для всех сервлетов

• Связано ли это с CPU? Если да, сколько циклов требуется или может быть безопасно преобразовано на некоторое время. например 1 мс только для вычислительной части работы.
• Связано ли это с вводом/выводом, если да, то аналогично найдите устройство.
• и другие
• Длинный список того, что у вас есть, например. CPU, память, GB/s

Теперь вы знаете, сколько работы нужно сделать, и все, что вы делаете, делит на то, что у вас есть, и продолжайте настройку, чтобы вы узнали об оптимальном, а также узнали, какой еще атрибут вы не рассматривали и не рассматривали.

Ответ 2

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

Это трудный вопрос для ответа из-за того, что каждое приложение отличается. Чтобы понять это для поддержки приложения, я создал unit test, который порождает много потоков, и я наблюдаю за использованием памяти в VisualVM в eclipse.

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

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

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

http://www4.ncsu.edu/~hp/SSME_QueueingTheory.pdf

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

Обновлен для ответа на ваши дополнительные вопросы:

Может ли мой сервер Tomcat обрабатывать 6000 одновременных HTTP-соединений? Почему нет (обрабатывает файлы? Процессорное время на запрос?)?

Возможно, но, возможно, нет. Также вы должны добавить веб-уровень перед сервером приложений, если вы планируете делать большой объем.
Предположим, что у вас 6000 пользователей, все избивают ваше приложение. Каждый запрос, который пользователь отправляет, существует на сервере только на мгновение [надеюсь], и ваш счетчик пиковых потоков может никогда не превышать 20.
Я бы рекомендовал настроить некоторый мониторинг, чтобы понять, как ваше приложение работает в реальных случаях использования. Проверьте http://Hawt.io, который использует Jolokia для захвата метрик JMX через http.
Если вы серьезно относитесь к аналитике, я бы рекомендовал использовать что-то вроде Graphite для агрегирования ваших показателей JMX. https://github.com/graphite-project/graphite-web
Я написал коллекционер для Jolokia для отправки показателей Carbon/Graphite и может с открытым исходным кодом с одобрения моего руководства. Дайте знать, если вас это заинтересовало.

Могу ли я иметь размер пула потоков как 5000 (нулевые потоки стоят CPU/RAM)?

Неактивные потоки не сильно беспокоятся, хотя установка слишком большого пула потоков может позволить серверу приложений получать слишком много запросов. Если это произойдет, вы можете наполнить свою БД подключениями, которые она не может обрабатывать, или выделение вашей памяти может оказаться недостаточным для обработки стольких запросов. Это может привести к ухудшению производительности приложений в целом.
Установите слишком низкий уровень, и ваш сервер приложений может снова запустить запрос на очередность, что приведет к ухудшению производительности.
Как правило, для очереди в периоды шипов или большого объема времени, но вы не хотите перегружать сервер приложений. Ознакомьтесь с теорией очередей, чтобы больше узнать об этом. Кроме того, здесь вам может помочь веб-сервер перед сервером приложений. Если вы используете Apache для статического контента, в большинстве случаев на серверы приложений попадают только динамические запросы.
Настройка очень специфична для вашего индивидуального приложения. Я бы рекомендовал оставаться с настройками по умолчанию и просто оптимизировать ваш код, пока вы не сможете собрать достаточно данных, чтобы узнать, какая ручка должна быть повернута.

Могу ли я иметь размер пула соединений оракула в виде 500 подключений (нечетные подключения стоят CPU/RAM)?

Такая же ситуация, как размер пула приложений. Хотя размер вашего пула для БД должен быть намного меньше, чем количество потоков приложений.
500 будет слишком высоким для большинства веб-приложений, если у вас не очень большой объем, и в этом случае вам может понадобиться среда кластера DB, такая как Oracle RAC.
Если пул установлен слишком высоко, и вы начнете использовать множество соединений, ваше аппаратное обеспечение БД не сможет идти в ногу с ним, и вы столкнетесь с проблемой производительности на сервере базы данных.
Время, затрачиваемое на возврат запроса, может увеличиться, в свою очередь, увеличивая время отклика приложения. Эффект "брелка".
Используйте профилирование или метрики для определения количества активных подключений БД при обычном использовании и используйте это как базовую линию для определения максимально допустимого.

Возникает ли количество мусора, создаваемого для каждого соединения? Например, если для каждого HTTP-соединения 20KB объектов создаются и оставлены Tomcat.. тогда к моменту обработки 2500 запросов будет использовано 100 мегабайт кучи, и это может вызвать паузу GC 300 мс.

Номера будут отличаться, но да. Также помните, что Full GC больше беспокоит. Инкрементные GC не приостанавливают ваше приложение. Проверьте "совпадающие метки и развертки" и "Сначала мусор".

Можем ли мы сказать что-то вроде этого: если Tomcat использует 0,2 секунды процессорного времени для обработки одного HTTP-запроса, тогда он сможет обрабатывать примерно 500 http-соединений за секунду. Таким образом, для 6000 соединений потребуется 5 секунд.

Это не так просто, как только каждый запрос поступает, есть и некоторые из них обрабатываются и завершаются. Ознакомьтесь с теорией очередей, чтобы понять это лучше. http://www4.ncsu.edu/~hp/SSME_QueueingTheory.pdf

Ответ 3

Существует еще одно общее узкое место: размер пула соединений с базой данных. Но у меня есть дополнительное замечание: когда вы исчерпаете количество разрешенных HTTP-соединений, количества потоков, разрешенных для запроса запроса, вы отклоняете только некоторые запросы. Но когда вы исчерпываете память (слишком много сеансов со слишком большим количеством данных, например), вы можете свернуть все приложение.

Разница в том, что в случае большой нагрузки в течение короткого времени, когда загрузка позже падает:

• в первом случае приложение работает и может нормально обслуживать запросы
• во втором случае приложение не работает и должно быть перезапущено

ИЗМЕНИТЬ:

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

• нет индекса в таблице с большим количеством строк
• запрос (на большой таблице), который не использует какой-либо индекс
• синдром n + 1: с ORM, когда вы привязываете отношение "один ко многим" к коллекции, не жадно, когда вам всегда нужны данные из коллекции.
• синдром полной загрузки нагрузки: при ORM, когда вы сопоставляете все отношения как нетерпеливые, любой отдельный запрос заканчивается при загрузке большого количества зависимых данных.

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

Ответ 4

Количество HTTP-соединений, которые сервер может разрешить для каждого порта

Неограниченно, кроме ресурсов ядра, например. FDs, soace буфера сокетов и т.д.

Количество HTTP-соединений, которые сервер может разрешать через несколько портов (у меня может быть несколько профилей WAS на нескольких HTTP-портах)

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

Количество сервлетов в пуле

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

Количество потоков, настроенных для использования WAS для обслуживания соединений

Релевантно косвенным образом, см. ниже.

ОЗУ, доступная для сервера (есть ли какая-либо корреляция между количеством потоков услуг, предполагающих утечку 0-памяти в приложении)

Релевантно, если он ограничивает количество потоков ниже настроенного количества потоков, упомянутых выше.

Основным ограничением является время обслуживания запроса. Чем короче, тем лучше. Чем дольше это происходит, тем дольше поток связывается в этом запросе, тем больше очереди ожидания получают,... Теория очередей диктует, что "сладкое пятно" - это не более 70% использования сервера. Кроме того, время ожидания растет с увеличением использования.

Таким образом, все, что способствует запросу времени на обслуживание, имеет большое значение: например, размер пула потоков, размер пула подключений, concurrency узкие места,...

Ответ 5

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

В java-land это может быть простой вещи, так как общий ресурс, который использует блокирующий доступ. (например, общие генераторы случайных чисел (не для потока), общие векторы, параллельные структуры, такие как ConcurrentHashMap и т.д.).

Чем больше синхронизация, тем меньше вы сможете полностью использовать аппаратное обеспечение сервера.

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

Ответ 6

Если вы видите пункт 6, вы можете использовать эти инструменты, чтобы узнать, является ли ваше оборудование узким местом. Предполагая, что вы работаете в Linux, вы можете использовать VmStat для просмотра статистики использования вашей оперативной памяти, top или atop (в зависимости от вашего дистрибутива), чтобы увидеть процессы, переносящие ваш процессор и оперативную память, nload и iftop, чтобы узнать, что потребляет сетевую полосу пропускания, и iotop, чтобы увидеть, что читает и записывает на ваш диск.