Определение максимального количества одновременных пользователей для веб-приложения Spring Reactive на сервере Netty

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

При создании стандартного веб-приложения (не реактивного), которое будет работать на Tomcat, вы можете просто определить количество веб-потоков, необходимых для поддержки ваших пользователей. Однако это не считается для веб-приложений Spring Reactive. Используется небольшое количество потоков и меньше памяти, но там, где в прошлом вы могли просто определить «X веб-потоков, доступных на сервер», это кажется невозможным. Делаем наших сисопов и devops друзей немного несчастными.

Какое решение этой проблемы? Потому что трудно «продать» реактивное решение, когда оно не очень детерминировано, когда оно может сломаться.


spring-webflux project-reactor netty
person Kristof    schedule 21.11.2017    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я понимаю, что потоки сервера могут быть метрикой, как и любая другая, для измерения количества ресурсов, которые вы хотите выделить серверу. Это работает с моделью «один запрос на поток», но также имеет свои ограничения. Как вы измеряете эффективность с помощью:

  • постоянные соединения, такие как события, отправленные сервером?
  • «медленные клиенты», очень медленно читающие HTTP-ответ?
  • потоки, ожидающие блокировки ввода-вывода (например, выполнение удаленного вызова REST)

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

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

В зависимости от вашего варианта использования приложение Spring MVC может работать лучше, чем приложение WebFlux: например, задержка и медленные клиенты не являются реальной проблемой в вашем приложении. Или приложение WebFlux может быть более предсказуемым, чем приложение Spring MVC: ваше приложение хорошо масштабируется под нагрузкой, а задержка не резко возрастает при достижении определенного уровня параллелизма.

TL;DR

Ничто не сравнится с сравнением вашего приложения с реальным трафиком и просмотром задержки 95-го процентиля.

person Brian Clozel    schedule 21.11.2017