Прекращает ли выполнение скрипт PHP, когда вы получаете 504 Gateway Timeout?


8

Я нахожусь на общем сервере (Siteground), и поскольку мой PHP-скрипт WordPress занимает более 30 секунд, он возвращает тайм-аут 504 шлюза.

Будет ли мой запрос выполняться и завершаться, если он не столкнется с дальнейшей ошибкой?

Изменить: я спросил, почему я получил эту ошибку для моей команды хостинга, здесь эксперт Siteground Hosting объяснил проблему следующим образом:

Мы используем Apache + Nginx на всех наших серверах. Apache используется для основного веб-сервиса, в то время как Nginx используется в качестве обратного прокси-сервера и распространяет кеш. Когда ответ не может быть обработан из кэша (обычно это относится к динамическому контенту), запрос от Nginx выполняется в сторону Apache. Это когда Apache обрабатывает запрос, перенаправляет его на ваш сайт и в соответствии с логикой PHP можно выполнять запросы MySQL или получать другие данные. Если этот процесс занимает слишком много времени и Apache не возвращает ответ своевременно Nginx, вы увидите эту ошибку. Короче говоря, Apache не может обработать запрос, поскольку приложение завершило процесс в течение разрешенного времени. Это также означает, что инициированный процесс, скорее всего, не был завершен полностью, и некоторые данные / действия могли быть сохранены / выполнены.

Эксперт говорит , что "initiated process most probably not completed fully",

Подробнее о моем сценарии: Мой сценарий добавляет продукты woocommerce с вариациями, используя wp_insert_postметод, на мой веб-сайт WordPress . После добавления продуктов отображаются изображения новых продуктов.

Когда я добавляю 1 товар (40 вариантов), он завершает и отображает изображение товара. Когда я добавляю 6 продуктов (240 вариантов), я получаю сообщение об ошибке прямо в своем браузере.

Поэтому для дальнейшего тестирования этой проблемы я изменил свой код и переписал его, используя ajax, и добавил панель процессов, подобную системе. (Который увеличивает число для каждого варианта).

После запуска кода для 1 продукта (с 40 вариантами) номер процесса увеличивается до 40, и на нем отображается изображение продукта.

Когда я запускаю свой код для продукта 6, номер процесса увеличивается до 240, но он ничего не отображает, а когда я проверяю, он получает ошибку 504. ( jQuery.Ajaxраздел ошибок функций)

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


1
Это может зависеть от того, откуда истекает время ожидания шлюза. Это интересный вопрос.
Стивен Остермиллер

@StephenOstermiller добавил еще несколько деталей на основе вашего комментария.
Привет

Предположительно, вы бы знали, завершен ли сценарий, если все «6 продуктов (240 вариантов)» были добавлены на ваш сайт? Или это сложно определить? Может быть, добавить некоторые функции ведения журнала в ваш сценарий?
MrWhite

Ответы:


3

Скрипт не остановится, пока не достигнет таймаута php.

Ошибка 504 генерируется на самом шлюзе / прокси, это не происходит от процесса php.

Это потому, что если у вас есть Apache с Apache-mod-php, вы никогда не получите эту ошибку, потому что нет прокси.

Расширяя объяснение, подумайте о следующем:

У вас есть процесс PHP. Процесс PHP может быть PHP-FPM, PHP-CGI или Apache-MOD-PHP. В этом процессе у вас есть тайм-аут (настроенный на php.ini или с ini_set).

Прокси-сервер PHP дает ответ в течение разрешенного времени (иначе: если у вас есть set_time_limit (600), ваш процесс PHP может работать до 10 минут).

Безотносительно к этому предложению у вас может быть другой процесс, ожидающий этот ответ: это случай Apache (настроенный для связи с php через cgi или fpm), nginx, lighthttpd и другие. Это не тот случай, когда apache настроен с помощью apache-mod-php. Этот второй процесс имеет новое время ожидания (proxy_timeout), настроенное в конфигурации приложения сервера vhost / general. В этот раз программа будет ждать ответа от обработчика PHP.

Последнее предложение может повторяться на каждом прокси / шлюзе.

Подумайте об этом сценарии:

haproxy (время ожидания 1) -> Nginx (внешний интерфейс / кэш) (время ожидания 2) -> Apache (время ожидания 3) -> PHP-FPM (время ожидания PHP / set_time_limit).

И очень простой сценарий:

Apache (с apache-mod-php) (PHP Timeout / set_time_limit).

Каждое появление тайм-аута (кроме самого PHP Timeout) является вероятным источником ошибки тайм-аута 504 HTTP-шлюза.


«если у вас есть Apache с Apache-mod-php, вы никогда не получите эту ошибку» - можете ли вы объяснить это последнее предложение?
MrWhite

Когда вы используете сервер Apache с mod-php, выполнение выполняется самим Apache. Из-за этого вы не можете получить тайм-аут 504, потому что в процессе нет шлюза. Если вы используете php-cgi или php-fpm, сервер Apache / nginx / некоторый другой веб-сервер действует как прокси или шлюз для реального процессора обработки. Затем появляется ошибка 504, когда этот шлюз не получил ответ в течение заданного времени.
Сакура Киномото

Но разве у вас не может быть обратного прокси-сервера Nginx перед Apache mod-php?
MrWhite

Очевидно, но это не сам вопрос. В этом случае 504 может быть задано nginx, но не Apache. В этом случае возникает вопрос: кто, если код ошибки 504 сгенерирован прокси, выполнение, вызванное вызовом прокси, не останавливается. В случае шлюза или прокси в игре есть как минимум два таймера. Тайм-аут соединения с прокси (например, в nginx) и тайм-аут процесса php.
Сакура Киномото

Я понимаю. Но ваше последнее предложение может показаться неполным в этом случае, поскольку оно подразумевает, что простое использование Apache-mod-php (независимо от того, существует ли внешний прокси-сервер или нет) позволит избежать этой ошибки. Я предполагаю, что вы имеете в виду ... «если у вас есть только Apache с Apache-mod-php и нет внешнего прокси (в данном случае Nginx), то вы никогда не получите эту ошибку»?
MrWhite

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.