Как обрабатывать многие медленные соединения

Пропускная способность нашего веб-приложения, по-видимому, ограничена медленными соединениями. В тестах нагрузки мы легко достигаем около 5000 запросов/с. Но на практике мы максимизируем примерно 1000 запросов/с. Сервер на самом деле не находится под серьезной нагрузкой, ни IO, ни процессор. То же самое относится к базе данных. Основное отличие состоит в том, что большинство рабочих потоков замедляются клиентами, которые не могут принять ответ достаточно быстро (часто количество ответов составляет несколько МБ).Как обрабатывать многие медленные соединения

У нас практически нет статических ресурсов. Проблема заключается в динамически создаваемом контенте. Он реализован с помощью Spring Framework. Но я думаю, что это не будет отличаться для любой другой реализации на основе сервлетов.

Итак, каковы наши варианты улучшения пропускной способности? Существует ли какое-то кеширование, которое быстро поглощает ответ, освобождает рабочие потоки, а затем асинхронно доставляет его клиенту с их скоростью?

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

источник

2016-12-25 Codo

Я нашел описание вашей проблемы с направлением для решения [здесь] (http://serverfault.com/a/406684). Nginx «обратный прокси» звучит [перспективным] (https://www.nginx.com/resources/admin-guide/reverse-proxy/). Если это сработает, сообщите нам в ответ на ваш собственный вопрос, возможно, мне это понадобится и в один прекрасный день. – vanOekel

Спасибо за подсказку. Да, обратное прокси nginx с включенной буферизацией похоже на то, что мы ищем. Потребуется некоторое время, чтобы настроить его и убедиться, что он увеличивает нашу пропускную способность в реальных условиях. – Codo

Я предлагаю вам использовать стандартные методы, такие как gzip для ответов.

Второй вариант - использовать асинхронную обработку в Spring MVC. См. Making a Controller Method Asynchronous, чтобы узнать больше об этом.

источник

2016-12-25 17:59:41

Мы уже используем сжатие для сжимаемых данных. И мое понимание асинхронных контроллеров заключается в том, что они решают другую проблему: они помогают, если ваше HTTP-соединение с клиентом простаивает, либо потому, что оно связано с событиями, либо потому, что сервер должен перенаправить запрос в другую систему и ждать долго. В нашем случае клиент является узким местом. Можете ли вы описать, как это можно применить для этого случая? Он действительно буферизует вывод до тех пор, пока клиент не поглотит его? – Codo

Использование асинхронных контроллеров дает возможность реализовать AsyncTaskExecutor с заданными размерами пула потоков и механизмом очередей, тогда как контроллеры будут обрабатывать новые запросы. Но если я правильно понял, вам следует рассмотреть архитектуру: 1) кластеризация приложения, 2) заменить выходной формат, чтобы уменьшить нагрузку на сеть, 3) вырезать вывод, 4) кэширование по прокси (например, nginx) и т. Д. В противном случае невозможно выводить больше данных, чем клиенты могут обрабатывать. –

Спасибо за ваши идеи. При более близком рассмотрении nginx как обратный прокси-сервер с буферизацией выглядит как действительный вариант (также предложенный vanOekel). Кластер потребует увеличения общего количества подключений к базе данных и, по-видимому, представляет собой отходы, учитывая, что у сервера есть запасные возможности процессора и ввода-вывода. У нас нет возможности заменить выходной формат. И все соединения уже используют выходной канал. – Codo

Как обрабатывать многие медленные соединения

ответ

Смежные вопросы