ajax, длинный опрос и управление двухминутными повторами


Один из запросов AJAX к моему узлу.JS-сервер может иногда занимать более двух минут. Я обнаружил, что когда сервер занимает больше двух минут, клиент повторно отправляет запрос AJAX. Это заставило сервер еще больше увязнуть, так как он запустил второй дорогостоящий процесс.

Чтобы обойти это, я реализовал решение для длительного опроса на сервере. Клиент делает ajax-вызов функции проверки на сервере, которая просто проверяет, завершен ли процесс и перепроверяет каждые пять секунд и возвращается к клиенту, когда это сделано.

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

Как лучше всего решить эту проблему?

  • есть ли способ настроить или отключить двухминутную повторную отправку ajax?
  • есть ли лучший способ управлять последующими дублировать запросы на сервер?
  • Нужно ли реализовывать таймаут на клиенте вместо сервера?

Я использую jQuery AJAX вызовы, узел.JS сервер в браузере Chrome

Обновление: с узла .JS docs , "все входящие соединения имеют таймаут по умолчанию 2 минуты". Меня по-прежнему интересуют предложения о наилучшей практике для кодирования длительных запросов сервера, когда клиенту не нужно ничего знать, пока сервер не закончит.

1 2

1 ответ:

Чтобы было понятно, что происходит:

  1. клиент посылает запрос " сделай это для меня ..."
  2. Код узла запускает асинхронную операцию (или несколько связанных вместе)
  3. проходит две минуты
  4. Время ожидания HTTP-запроса
  5. клиент повторно отправляет запрос
  6. теперь есть два запущенных запроса
  7. и так далее, пока не наберется тонна запросов

Мне кажется, я слышал, что это называется "эффект догпайла". Я не знаю никакого стандарта. библиотеки в узле.js или jQuery, чтобы помочь вам, хотя кто-то начал работу над кэширующим прокси, чтобы помочь с этим в случае, когда ответ будет "кэшируемым":

Https://github.com/simonw/dogproxy

Итак, вам придется разработать свою собственную систему, чтобы обойти это.

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

Что я видел чаще всего для задач, которые занимают много времени, API возвращает идентификатор для выполнения задания сразу, а затем клиент использует опрос (или длинный опрос), чтобы дождаться завершения задания. Вам понадобится какая-то база данных для хранения состояния (% complete) и результата задания и позволяет клиенту ждать изменения этого состояния. Это также может позволить вам "отменить" задание, хотя в этом случае код на стороне сервера должен периодически проверять, не было ли оно отменено.

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