ajax, длинный опрос и управление двухминутными повторами
Один из запросов AJAX к моему узлу.JS-сервер может иногда занимать более двух минут. Я обнаружил, что когда сервер занимает больше двух минут, клиент повторно отправляет запрос AJAX. Это заставило сервер еще больше увязнуть, так как он запустил второй дорогостоящий процесс.
Чтобы обойти это, я реализовал решение для длительного опроса на сервере. Клиент делает ajax-вызов функции проверки на сервере, которая просто проверяет, завершен ли процесс и перепроверяет каждые пять секунд и возвращается к клиенту, когда это сделано.
Тем не менее, у меня все еще есть вариант двухминутной задачи. Через две минуты приходит второй чек-Аякс по-прежнему звонит. Затем выполняются обе проверки, и кажется, что только новая будет связываться с клиентом.Как лучше всего решить эту проблему?
- есть ли способ настроить или отключить двухминутную повторную отправку ajax?
- есть ли лучший способ управлять последующими дублировать запросы на сервер?
- Нужно ли реализовывать таймаут на клиенте вместо сервера?
Я использую jQuery AJAX вызовы, узел.JS сервер в браузере Chrome
Обновление: с узла .JS docs , "все входящие соединения имеют таймаут по умолчанию 2 минуты". Меня по-прежнему интересуют предложения о наилучшей практике для кодирования длительных запросов сервера, когда клиенту не нужно ничего знать, пока сервер не закончит.
1 ответ:
Чтобы было понятно, что происходит:
- клиент посылает запрос " сделай это для меня ..."
- Код узла запускает асинхронную операцию (или несколько связанных вместе)
- проходит две минуты
- Время ожидания HTTP-запроса
- клиент повторно отправляет запрос
- теперь есть два запущенных запроса
- и так далее, пока не наберется тонна запросов
Мне кажется, я слышал, что это называется "эффект догпайла". Я не знаю никакого стандарта. библиотеки в узле.js или jQuery, чтобы помочь вам, хотя кто-то начал работу над кэширующим прокси, чтобы помочь с этим в случае, когда ответ будет "кэшируемым":
Https://github.com/simonw/dogproxy
Итак, вам придется разработать свою собственную систему, чтобы обойти это.
Существуют различные способы обработки пакетных заданий, и часто это зависит от характера задания.
Что я видел чаще всего для задач, которые занимают много времени, API возвращает идентификатор для выполнения задания сразу, а затем клиент использует опрос (или длинный опрос), чтобы дождаться завершения задания. Вам понадобится какая-то база данных для хранения состояния (% complete) и результата задания и позволяет клиенту ждать изменения этого состояния. Это также может позволить вам "отменить" задание, хотя в этом случае код на стороне сервера должен периодически проверять, не было ли оно отменено.
Просто имейте в виду, что где бы вы ни хранили статус задания, он должен быть общим для всех узлов сети. кластер, если приложение масштабируется или будет масштабироваться позже. Для этого можно использовать какую-нибудь высокоскоростную облегченную систему хранения, например memcached или redis.