Тайм-аут HTTP 504 ровно через 120 секунд - PullRequest
7 голосов
/ 13 июля 2010

У меня есть серверное приложение, которое работает в облаке Amazon EC2. От моего клиента (браузера) я делаю HTTP-запрос, который загружает файл на сервер, который затем обрабатывает файл. Если есть много обработки (большой файл ), сервер всегда прерывается с ошибкой продолжения бэкэнда 504 всегда точно через 120 секунд. Хотя я получаю эту ошибку, сервер продолжает обрабатывать запрос и завершает его (проверено проверкой базы данных), но я не вижу окончательного результата на моем клиенте из-за истечения времени ожидания.

Я понятия не имею, почему это происходит. Кто-нибудь сталкивался с подобным таймаутом 504? Какой-то промежуточный прокси-сервер не в моем контроле, который истекает?

Ответы [ 3 ]

7 голосов
/ 03 октября 2013

У меня похожая проблема, и в моем случае я полагаю, что это связано с соединением между Elastic Load Balancer (ELB) и экземпляром EC2.

Для долгосрочного решения я остановлюсь на303 Статус ответа + внутренняя обработка, предложенная james.garriss выше.

Для краткосрочного решения поддержка Amazon может увеличить время ожидания ELB (см. Их ответ в https://forums.aws.amazon.com/thread.jspa?messageID=491594&#491594). К сожалению, похоже, нет способа изменитьТайм-аут самостоятельно через API или консоль.

[ Обновление ] Теперь AWS позволяет обновлять время простоя через консоль, интерфейс командной строки или .ebextensions.http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/config-idle-timeout.html (спасибо @Daniel Patz за обновление)

2 голосов
/ 13 декабря 2011

При условии, что возвращается правильный код состояния, проблема в том, что промежуточный прокси-сервер истекает. «Сервер, действуя как шлюз или прокси, не получил своевременный ответ от вышестоящего сервера, указанного в URI». (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.5) Скорее всего, это означает, что у исходного сервера возникла какая-то проблема (т. Е. Требуется много времени для обработки вашего запроса), поэтому он не отвечает быстро.

Возможно, лучшим решением будет переделать ваше серверное приложение, чтобы оно отвечало кодом состояния «303 See Other»; затем ваш клиент может получить данные на более позднем этапе, когда сервер завершит обработку и создаст окончательный результат.

Редактировать. Другая идея заключается в том, чтобы изменить приложение сервера так, чтобы оно отвечало кодом состояния «413 Request Entity Too Large», когда размер объекта запроса слишком велик. Это избавит от ошибки, хотя может сделать ваше приложение менее полезным, если оно сможет обрабатывать только «маленькие» файлы. "

Другие возможные решения:

  • Увеличить значение тайм-аута прокси (если оно находится под вашим контролем)
  • Сделайте запрос на другой сервер (если есть другой, более быстрый сервер с тем же приложением)
  • Сделайте ваш запрос по-другому (если это возможно) так, чтобы вы отправляли меньше данных за раз
0 голосов
/ 11 декабря 2010

возможно, что время ожидания браузера истекло во время выполнения скрипта.

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