Прекращает ли выполнение скрипт 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.