Ограничение количества запросов к сервлету

Question

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

Можно ли создать собственный пул потоков и назначить этому сервлету для обработки этого сценария? Мы используем сервер WebLogic 9.2. Или есть другой лучший способ сделать это? Цени любые мысли.

Answer 1

Можно ли создать собственный пул потоков и назначить этому сервлету для обработки этого сценария? Мы используем сервер WebLogic 9.2. Или есть другой лучший способ сделать это? Цени любые мысли.

Да, это возможно. Вместо использования стандартного самонастраивающегося менеджера работ (начиная с Weblogic 9.x очереди выполнения заменяются менеджерами работ для пулов потоков ¹ ), вы можете создать менеджер работ с специфические ограничения , такие как max-threads-constraint и, возможно, capacity. Затем вы можете назначить сервлет определенному менеджеру работ, используя wl-dispatch-policy файла дескриптора развертывания weblogic.xml.

---

¹ Обратите внимание, что все еще возможно включить Модель пула потоков WebLogic 8.1 и использовать Очереди выполнения.

Answer 2

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

Возможно, вам нужен балансировщик нагрузки, программный или аппаратный, в зависимости от ваших целевых требований. Программный балансировщик нагрузки может быть просто «сервлетом-диспетчером» с управлением сеансом (например, 10 одновременно с сервлетом X).

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

Answer 3

Мне нравится идея использования статического счетчика и перенаправления для отображения сообщения об ошибке, когда счетчик достиг предела.

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

http://download.oracle.com/docs/cd/E13222_01/wls/docs92/perform/appb_queues.html

Answer 4

Без использования балансировщиков нагрузки и т. Д. Мне кажется, что вы хотите отделить запрос от обработки.

например.

1. браузер отправляет запрос. Сервлет берет его, ставит в очередь и возвращает билет.
2. Сервлет будет работать над этим рабочим запросом, если позволяют ресурсы (используя отдельный пул потоков, извлекающий рабочие элементы из очереди).
3. Браузер может обновить (повторно получить), используя этот билет, и сервлет вернет соответствующий результат (например, не обрабатывает, не обрабатывает, обрабатывает).

Это довольно распространенная модель. Обратите внимание, что браузер не блокируется, а просто отправляет запрос, а затем регулярно выполняет проверки, чтобы увидеть, завершен ли рабочий элемент. Я успешно использовал это (например) в ситуации, когда у меня были пользователи, запрашивающие диаграммы, обработка которых занимает 5 минут или более, и которые использовали собственную библиотеку, которая не была поточно-ориентированной. В этом сценарии у меня было , чтобы ограничить обработку одним потоком независимо от количества одновременных запросов.

Answer 5

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

Итак, вы бы превратили ваш текущий сервлет в вызов метода.

Затем сервлет шлюза получит запрос, посмотрит, достаточно ли низкий счетчик, а затем увеличит его. Если больше 10, верните сообщение об ошибке.

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

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

Answer 6

Вы можете распределить нагрузку таким образом, чтобы существовал вторичный сервер, который обрабатывает все запросы на дорогой сервлет.