Ограниченная полезность AsyncContext.start ()

Некоторое время назад я столкнулся с тем, какова цель AsyncContext.start (…) в Servlet 3.0? вопрос. Цитирование Javadoc вышеупомянутого метода :

Заставляет контейнер отправлять поток, возможно из пула управляемых потоков, для запуска указанного Runnable.

Напомним, что AsyncContext — это стандартный способ, определенный в спецификации Servlet 3.0, для асинхронной обработки HTTP-запросов. По сути, HTTP-запрос больше не привязан к HTTP-потоку, что позволяет нам обрабатывать его позже, возможно, используя меньшее количество потоков. Оказалось, что спецификация предоставляет API для обработки асинхронных потоков в другом пуле потоков. Сначала мы увидим, как эта функция полностью сломана и бесполезна в Tomcat и Jetty, а затем обсудим, почему ее полезность в целом сомнительна.

Наш тестовый сервлет просто будет спать в течение заданного количества времени. В нормальных обстоятельствах это убивает масштабируемость, потому что хотя спящий сервлет не потребляет ЦП, но спящий HTTP-поток, связанный с этим конкретным запросом, потребляет память — и никакой другой входящий запрос не может использовать этот поток. В нашей тестовой настройке я ограничил количество рабочих потоков HTTP до 10, что означает, что только 10 одновременных запросов полностью блокируют приложение (оно не отвечает извне), даже если само приложение почти полностью бездействует. Итак, ясно, что сон — враг масштабируемости.

@WebServlet(urlPatterns = Array("/*"))
class SlowServlet extends HttpServlet with Logging {
 
  protected override def doGet(req: HttpServletRequest, resp: HttpServletResponse) {
    logger.info("Request received")
    val sleepParam = Option(req.getParameter("sleep")) map {_.toLong}
    TimeUnit.MILLISECONDS.sleep(sleepParam getOrElse 10)
    logger.info("Request done")
  }
}

Сравнительный анализ этого кода показывает, что среднее время ответа близко к параметру сна, если количество одновременных подключений меньше количества потоков HTTP. Неудивительно, что время отклика начинает расти, как только мы превышаем количество потоков HTTP. Одиннадцатое соединение должно ждать завершения любого другого запроса и освобождать рабочий поток. Когда уровень параллелизма превышает 100, Tomcat начинает сбрасывать соединения — слишком много клиентов уже поставлено в очередь.

Так что насчет необычного метода AsyncContext.start () (не путайте с ServletRequest.startAsync ())? В соответствии с JavaDoc я могу передать любой Runnable, и контейнер будет использовать некоторый пул управляемых потоков для его обработки. Это поможет частично, так как я больше не блокирую рабочие потоки HTTP (но еще один поток где-то в контейнере сервлета используется). Быстрое переключение на асинхронный сервлет:

@WebServlet(urlPatterns = Array("/*"), asyncSupported = true)
class SlowServlet extends HttpServlet with Logging {
 
  protected override def doGet(req: HttpServletRequest, resp: HttpServletResponse) {
    logger.info("Request received")
    val asyncContext = req.startAsync()
    asyncContext.setTimeout(TimeUnit.MINUTES.toMillis(10))
    asyncContext.start(new Runnable() {
      def run() {
        logger.info("Handling request")
        val sleepParam = Option(req.getParameter("sleep")) map {_.toLong}
        TimeUnit.MILLISECONDS.sleep(sleepParam getOrElse 10)
        logger.info("Request done")
        asyncContext.complete()
      }
    })
  }
}

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

Угадайте, что время отклика
точно такое же, как и при отсутствии асинхронной поддержки вообще (!) После более внимательного изучения я обнаружил, что при вызове AsyncContext.start () Tomcat отправляет заданную задачу обратно … пулу рабочих потоков HTTP, то же самое тот, который используется для всех запросов HTTP! По сути, это означает, что мы выпустили один поток HTTP, чтобы использовать другой через миллисекунды (возможно, даже тот же). Вызывать AsyncContext.start () в Tomcat абсолютно бесполезно
, Я понятия не имею, это ошибка или особенность. С одной стороны, это явно не то, что намеревались разработчики API. Предполагалось, что контейнер сервлета управляет отдельным независимым пулом потоков, поэтому пул рабочих потоков HTTP все еще можно использовать. Я имею в виду, что весь смысл асинхронной обработки состоит в том, чтобы избежать пула HTTP. Tomcat делает вид, что делегирует нашу работу другому потоку, хотя он все еще использует исходный пул рабочих потоков.

implicit def blockToRunnable[T](block: => T) = new Runnable {
 def run() {
  block
 }
}

asyncContext start {
 logger.info("Handling request")
 val sleepParam = Option(req.getParameter("sleep")) map { _.toLong}
 TimeUnit.MILLISECONDS.sleep(sleepParam getOrElse 10)
 logger.info("Request done")
 asyncContext.complete()
}