Потоки в веб-сервисе Java REST

Question

У меня есть веб-служба REST, которая потребляет слишком много ресурсов ЦП, когда число запросов становится слишком большим.

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

Исправление для этого, по-видимому, заключается в использовании wait () и notify () в соответствии с this , однако я не понимаю, почему это уменьшит загрузку процессора?

Будет ли этот новый поток обрабатываться за пределами веб-службы, что освобождает его для обработки большего количества запросов?Может кто-нибудь объяснить, пожалуйста?

Спасибо!

Джон.

Редактировать:

Возможно, я нашел свой собственный ответ здесь

Кажется, что мой код result = get() постоянно опрашивает, пока не получится ответ, который потребляет больше ресурсов процессора.При размещении этого в потоке потребляется меньше ресурсов.

Это правильное понимание?

Answer 1

Это правильное понимание?

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

Не зная точно, что вы делаете (что опрашиваете и почему), немного сложно сказать, что такое решение best .Но вот несколько возможных сценариев:

• Если ваш веб-сервис ожидает ответа от внешнего сервиса, то простое решение - просто выполнить чтение блокировки и настроитьвеб-сервер с большим количеством рабочих потоков.

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

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

---

СЛЕДУЙТЕ ЗА

... Я думаю, проблема в том, что вы говорите 2, что сервис просто ожидает вычислений.Таким образом, простое выполнение этих вычислений высвободит ресурсы в сервисе?

Если то, что вы описываете, верно, то выполнение вычисления в другом потоке не заставит его идти намного быстрее.Фактически, это может замедлить работу.

Конечным узким местом будет емкость процессора, пропускная способность диска и / или пропускная способность сети.Многопоточность только ускорит выполнение отдельного запроса, если вы сможете эффективно / рационально использовать 2 или более процессоров по одному и тому же запросу одновременно.Это только улучшит вашу пропускную способность в той степени, в которой оно позволяет выполнять запросы, пока другие ожидают внешних событий;например, сетевые ответы для получения или файловые операции чтения / записи для завершения.

Я думаю, что вам действительно нужно сделать, это выяснить, почему вычисления занимают так много времени, и попытаться исправить это:

• Ваши запросы к базе данных неэффективны?
• Получаются ли слишком большие наборы результатов?
• У вас есть проблемы с вашими схемами?
• Плохой выбор индексов?
• Или вы просто пытаетесь сделать слишком много на машине, которая слишком мала, используя неправильную базу данных?

Существуют различные методы измерения производительность службы приложений и базы данных для определения узких мест.(Начните с поиска Google ....)

Answer 2

Во-первых, перестаньте пытаться угадать, почему он потребляет так много ресурсов процессора.Поместите некоторые инструменты и узнайте, где на самом деле находится горлышко бутылки.Как только вы знаете, где находится бутылочное горлышко, попытайтесь понять причину. 5 почему - это хорошая техника для использования при этом.

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

Во-вторых, рассмотрите возможность использования кэша http для уменьшения нагрузки на ваш сервер.Как часто запрашиваемые данные меняются и насколько свежими должны быть ваши ответы?Используйте это, чтобы рассчитать максимальный возраст;время, в течение которого HTTP-кеш может хранить ответ.Это может быть 1 минута, день, неделя и т. Д. Это действительно зависит от того, что вы подаете.Как только у вас будет максимальный возраст, посмотрите на поступающие запросы. Сколько будет для того же URI (или может быть для того же URI, если вы настроили его) в выбранном вами максимальном возрасте.Если все URI запроса в течение максимального возраста уникальны, кэширование вам не поможет.Если вы получаете в среднем 2 запроса на каждый URI за период максимального возраста, то кэш HTTP будет вдвое меньше загружать ваш сервер.Если это 10 запросов на URI, то кеш HTTP уменьшит нагрузку на сервер на 90%.