могут ли новые веб-контейнеры с Servlet 3 расширять BlazeDS max # одновременных пользователей? - PullRequest
Новая
       37

могут ли новые веб-контейнеры с Servlet 3 расширять BlazeDS max # одновременных пользователей?

4 голосов
/ 03 февраля 2012

BlazeDS реализован в виде сервлета и, следовательно, ограничен примерно сотнями одновременных пользователей.

Интересно, могли бы более свежие веб-контейнеры (Tomcat 7, GlassFish / Grizzly, Jetty и т. Д.) Поддерживать Servlet 3быть использованы для создания конечных точек NIO, чтобы увеличить число одновременных пользователей до тысяч?

Это правильное и практичное решение?Кто-нибудь делает это в производстве?

Что-то вроде зрелой версии этого: http://flex.sys -con.com / node / 720304 Если это было очень важно тогда, почему сейчас (когдаСервлет 3 широко доступен). Не было ли попыток реализовать конечные точки NIO?(обратите внимание, я новичок здесь, поэтому не стесняйтесь заявить очевидное, если я что-то упустил)

Преимущество NIO: http://www.javalobby.org/java/forums/t92965.html

Если нет, балансировщик нагрузки инесколько серверов приложений, каждый из которых имеет экземпляр BlazeDS, рекомендуемое решение (кроме перехода на LCDS и т. д.)?

1 Ответ

3 голосов
/ 03 февраля 2012

GraniteDS и асинхронные сервлеты

GraniteDS, насколько мне известно, единственное решение, которое реализует асинхронные сервлеты для обмена сообщениями в реальном времени, т.е.передача данных.Эта функция доступна не только для контейнеров Servlet 3 (Tomcat 7, JBoss 7, Jetty 8, GlassFish 3 и т. Д.), Но также для более старых или других контейнеров с определенной асинхронной поддержкой (например, Tomcat 6 / CometProcessor, WebLogic 9 + / AbstractAsyncServletи т. д.)

Другие решения не имеют этой функции (BlazeDS) или не используют RTMP (LCDS, WebORB и последнюю версию Clear Toolkit).Я не могу сказать много о реализациях RTMP, но в BlazeDS явно отсутствует масштабируемая реализация обмена сообщениями в режиме реального времени, поскольку она использует только модель синхронного сервлета.

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

Производительность асинхронных сервлетов

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

При использовании сервера без NIO или без Continuation для этого потребуется около 11 000 потоков.обрабатывать 10000 одновременных пользователей.Jetty обрабатывает это количество соединений только с 250 потоками .

Классическая синхронная модель:

  • 10 000 одновременных пользователей -> 11 000 серверных потоков.
  • 1.1 коэффициент.

Асинхронная модель кометы:

  • 10000 одновременных пользователей -> 250 потоков сервера.
  • 0.025 коэффициент.

Такое соотношение можно примерно ожидать от других асинхронных реализаций (не Jetty), и использование Flex / AMF3 вместо простого HTTP-запроса HTTP не должно сильно влиять на результат.

Почему асинхронныйСервлеты?

Классическая (синхронная) модель сервлетов приемлема, когда каждый запрос обрабатывается немедленно: 

    request -> immediate processing -> response

Проблема с передачей данных заключается в том, что не существует такой вещи, как настоящие "данныеpush "с протоколом HTTP: сервер не может инициировать вызов клиента для отправки данных, он должен ответить на запрос .Вот почему реализации Comet основаны на другой модели: 

    request -> wait for available data -> response

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

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

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

...