зачем нужен цикл обработки событий для асинхронных запросов (например, длинный опрос AJAX)

Question

Я понимаю, что использование длинного опроса AJAX для обычного многопоточного веб-сервера (например, Apache) считается плохим дизайном ... но я не совсем понимаю, почему.

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

Answer 1

Просто чтобы уточнить, опрос AJAX - это когда клиентский javascript делает запрос AJAX, который не выполняется немедленно. Вместо этого сервер ждет, пока он не хочет отправить ответ клиенту, а затем использует для этого уже открытый контекст AJAX. (Правильно?)

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

Answer 2

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

Если ваше приложение пытается конкурировать с Facebook, у вас есть серьезная проблема, если это внутреннее приложение в МСП для заказа обеда,никто не пострадает.

Answer 3

Это на самом деле не вопрос, поскольку он имеет различные факторы, которые могут повлиять на ответ.

Например, используете ли вы yaws (веб-сервер, написанный на Erlang)? Тогда это не будет проблемой, за исключением того, что вы подключаете порты на веб-сервере, но потоки не являются проблемой.

Используете ли вы Java NewIO API, чтобы каждое соединение не занимало выделенный поток, тогда это не будет проблемой для потоков.

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

Храните ресурсы столько, сколько вам нужно.

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

Например, укажите какой-то уникальный номер, который пользователь может использовать, чтобы проверить, выполнен ли его запрос, чтобы он мог выключить свой компьютер или просто проверить его в любое время, не беспокоясь о потере чего-либо.