Назад | Перейти на главную страницу

Nginx 504 Тайм-аут при архивировании / разархивировании и перемещении файлов

Мы получаем тайм-аут 504 в Wordpress с функцией, которую мы прикрепили к «публикации сообщения», которая берет атакованный zip-файл, распаковывает его, перемещает распакованные файлы в s3, создает новый Zip и перемещает его также в S3. Для больших файлов время ожидания истекает через 60 секунд.

Могу я сейчас пояснить, что ISNT - это функция пользователя - этого не происходит из внешнего интерфейса сайта, когда пользователь что-либо делает. Пользователь загружает изображения содержимого, zip и т. Д. В сообщение, которое ждет нас в панели администратора. После модерации мы можем удалить сообщение (которое удаляет все данные, которые они загрузили одновременно) или опубликовать сообщение, которое затем берет загруженный ими zip, разархивирует его, проверяет на вирусы, удаляет все, что не является MP3, загружает отдельные MP3-файлы в S3, создает новый zip-файл и также загружает его в S3. Все это работает с EC2. Как вы понимаете, хотя это не создает слишком большой нагрузки на ЦП сервера, для перемещения всех этих данных в S3 часто требуется больше 60 секунд.

Итак, я видел предложения о том, как предотвратить тайм-аут шлюза с помощью Nginx

Я поместил fastcgi_read_timeout в свой nginx.conf и установил для него (на данный момент) значение 2700, пытаясь избежать всех ошибок тайм-аута. Я сделал это со всем, что связано с тайм-аутами. Я также добавил client_body_timeout и send_timeout, как упоминалось на этой странице. Но все же время ожидания процесса составляет 60 секунд.

Могу ли я поместить их в неправильное место в nginx.conf (он перезапускается без проблем), используя неправильное время, или, возможно, есть другая функция, которая позволит завершить этот php-процесс.

У меня есть все времена php-fpm, пока я их тоже могу установить.

HTTP-запросы не могут жить вечно - либо сервер, либо клиент в конечном итоге откажутся (самые щедрые тайм-ауты на стороне сервера для HTTP-запросов обычно составляют 5-10 минут, и пользователи часто сдаются до этого и начинают нажимать кнопку перезагрузки - практически гарантированный способ убить ваш сервер).

подобно Майкл Хэмптон сказал, что вам нужно изменить дизайн вашего приложения, чтобы учесть тот факт, что у вас есть этап фоновой обработки, который может занять много времени.

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