Конфигурирование спрей-сервлетом во избежание узкого места запроса

Question

У меня есть приложение, которое использует spray-servlet для загрузки моего пользовательского маршрута с использованием распыления с помощью spray.servlet.Initializer. Запросы затем передаются моему Актеру через spray.servlet.Servlet30ConnectorServlet.

Из того, что я могу собрать, то Servlet30ConnectorServlet просто извлекает свою Актеру из ServletContext, что Initializer был установлен при запуске приложения, и вручает HttpServletRequest получить метод моего актера. Это заставляет меня думать, что только один из моих экземпляр моего Актера должен будет обрабатывать все запросы. Если мой Актер блокирует свой метод receive, последующие запросы будут стоять в очереди, ожидая его завершения.

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

Если мое вышеприведенное предположение верно (отдельный экземпляр Actor обрабатывает все запросы), существует ли способ настроить Servlet30ConnectorServlet, чтобы, возможно, балансировать входящие запросы среди нескольких экземпляров моего участника маршрутизации, а не только одного? Или это что-то, что мне придется катить себя подклассированием Servlet30ConnectorServlet?

Answer 1

Я провел некоторое исследование, и теперь я лучше понимаю, как работает spray-servlet. Это не spray-servlet, который диктует стратегию для того, сколько создателей-обработчиков запросов создаются, а скорее всего сантехнический код с the example I based my application on.

Мое предположение все время состояло в том, что spray-servlet будет по существу работать как традиционный диспетчер приложений Java EE в режиме обработчика за запрос (или какой-либо разумный вариант этого понятия). Это не так, потому что он направляет запрос Актеру с почтовым ящиком, а не какой-то однотонный HttpServlet.

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

val serviceActor = system.actorOf(RoundRobinPool(config.SomeReasonableSize).props(Props(Props[BootServiceActor])), "my-route-actors")

Я все еще немного сбит с толку тем, что примеры и документация предполагает все будут писать неблокируемому Request Handler Актеры под распылителем. Вся их документация по существу демонстрирует не-будущий рендеринг complete, но в их литературе нет упоминания о том, что, может быть, возможно, вам захочется создать разумный размер пула актеров-обработчиков запроса, чтобы предотвратить множество запросов от бутылки, шеивших бедных одиночный перегруженный актером. Или, возможно, я упустил это.