Поддерживать подключение Elastic Load Balancer во время длинного запроса AJAX
Я сталкиваюсь с этой проблемой:
- Я отправляю запрос на сервер, используя AJAX, который принимает некоторые параметры, и на стороне сервера генерирует PDF.
- Создание PDF может занять много времени в зависимости от используемых данных
- Elastic Load Balancer от AWS, после 60 секунд простоя соединения, решает сбросить сокет, и поэтому в этом случае мой запрос не выполняется.
Я знаю, что можно увеличить время ожидания в настройках ELB, но не только мой системный администратор против этого, это также ложное решение и плохая практика.
Я понимаю, что лучший способ решить эту проблему — это послать данные через сокет, чтобы «сказать ELB», что я все еще активен. Отправка фиктивного запроса на сервер каждые 30 с не работает из-за нашей архитектуры и того факта, что сеанс заблокирован (т. Е. У нас не может быть одновременных запросов AJAX из одного и того же сеанса, в противном случае один ожидает, пока другой не завершится)
Я попытался просто выполнить запрос get к файлам на сервере, но это не имеет значения, я предполагаю, что «сокет» — это тот, который использовался исходным вызовом AJAX.
Функция на сервере довольно линейная, и ее практически невозможно разделить на несколько вызовов, и идея запустить ее в фоновом режиме и проверять каждые 5 секунд до ее завершения вызывает у меня неудобства с точки зрения управления ресурсами.
TL; DR: есть ли какое-нибудь элегантное и эффективное решение для поддержания сокета активным, пока AJAX-запрос находится на рассмотрении?
Большое спасибо, если кто-то может помочь с этим, я нашел пару похожих вопросов на SO, но на оба они отвечают «позвоните в команду amazon, чтобы попросить их увеличить время ожидания в ваших настройках», что звучит очень плохо для меня.
Решение
Я сталкиваюсь с этой проблемой:
- Я отправляю запрос на сервер, используя AJAX, который принимает некоторые параметры, и на стороне сервера генерирует PDF.
- Создание PDF может занять много времени в зависимости от используемых данных
- Elastic Load Balancer от AWS, после 60 секунд простоя соединения, решает сбросить сокет, и поэтому в этом случае мой запрос не выполняется.
Я знаю, что можно увеличить время ожидания в настройках ELB, но не только мой системный администратор против этого, это также ложное решение и плохая практика.
Я понимаю, что лучший способ решить эту проблему — это послать данные через сокет, чтобы «сказать ELB», что я все еще активен. Отправка фиктивного запроса на сервер каждые 30 с не работает из-за нашей архитектуры и того факта, что сеанс заблокирован (т. Е. У нас не может быть одновременных запросов AJAX из одного и того же сеанса, в противном случае один ожидает, пока другой не завершится)
Я попытался просто выполнить запрос get к файлам на сервере, но это не имеет значения, я предполагаю, что «сокет» — это тот, который использовался исходным вызовом AJAX.
Функция на сервере довольно линейная, и ее практически невозможно разделить на несколько вызовов, и идея запустить ее в фоновом режиме и проверять каждые 5 секунд до ее завершения вызывает у меня неудобства с точки зрения управления ресурсами.
TL; DR: есть ли какое-нибудь элегантное и эффективное решение для поддержания сокета активным, пока AJAX-запрос находится на рассмотрении?
Большое спасибо, если кто-то может помочь с этим, я нашел пару похожих вопросов на SO, но на оба они отвечают «позвоните в команду amazon, чтобы попросить их увеличить время ожидания в ваших настройках», что звучит очень плохо для меня.
Другие решения
Другой подход состоит в том, чтобы разделить все операции на две службы:
- Первый сервис принимает HTTP-запрос для генерации PDF-документа. Эта услуга заканчивается сразу после принятия запроса. И он вернет UUID или URL для проверки результата
- Второй сервис принимает UUID и возвращает документ PDF, если он готов. Если документ PDF не готов, эта служба может вернуть код ошибки, например HTTP 404.
Поскольку вы используете AJAX для вызова серверной части, вам будет легко изменить свой javascript и вызвать 2-й сервисный сервер, когда 1-й сервис завершится успешно. Будет ли это работать для вашего сценария?
Вы пытались следовать руководство по устранению неисправностей ELB? Цитируется соответствующая часть ниже:
HTTP 504: время ожидания шлюза
Описание: указывает, что балансировщик нагрузки закрыл соединение
потому что запрос не был выполнен в течение периода простоя.Причина 1: приложение отвечает дольше, чем настроено
время простояРешение 1. Проверьте метрики HTTPCode_ELB_5XX и Latency. Если там
это увеличение этих показателей, это может быть связано с применением
не отвечает в течение периода ожидания простоя. Для получения подробной информации о
Тайм-аут запросов, включить журналы доступа на балансировщик нагрузки
и просмотрите 504 коды ответов в журналах, которые сгенерированы
Упругая балансировка нагрузки. При необходимости вы можете увеличить свои возможности
или увеличьте настроенное время простоя, чтобы длительные операции
(например, загрузка большого файла) можно завершить.Причина 2: зарегистрированные экземпляры, закрывающие соединение с Elastic Load
Балансировка.Решение 2. Включите настройки поддержки активности на экземплярах EC2 и установите
время ожидания активности больше или равно времени простоя
настройки вашего балансировщика нагрузки.