¿Un script PHP deja de ejecutarse cuando recibe 504 Gateway Timeout?

8

Estoy en un servidor compartido (Siteground), y dado que mi script PHP de WordPress tarda más de 30 segundos, devuelve un tiempo de espera de 504 Gateway.

¿Mi consulta se ejecutará y completará si no encuentra un error adicional?

Editar: pregunté por qué recibí este error a mi equipo de alojamiento, aquí el experto en alojamiento de Siteground explicó el problema de la siguiente manera:

Usamos Apache + Nginx en todos nuestros servidores. Apache se usa para el servicio web principal, mientras que el Nginx se usa como proxy inverso y caché de distribución. Cuando la respuesta no se puede servir desde el caché (generalmente esto se refiere al contenido dinámico), se realiza una solicitud de Nginx hacia Apache. Esto cuando Apache procesa la solicitud, la reenvía a su sitio web y de acuerdo con la lógica de PHP, se pueden realizar consultas MySQL u otros datos recuperados. Cuando este proceso lleva demasiado tiempo y Apache no devuelve la respuesta de manera oportuna a Nginx, verá este error. En resumen, Apache no puede atender la solicitud ya que la aplicación completó el proceso dentro del tiempo permitido. Esto también significa que el proceso iniciado probablemente no se completó completamente y algunos datos / acciones podrían haberse guardado / ejecutado.

El experto dice que "initiated process most probably not completed fully",

Más detalles sobre mi escenario: mi script agrega productos de WooCommerce con variaciones utilizando el wp_insert_postmétodo a mi sitio web de WordPress. Después de agregar productos, muestra las imágenes de los productos recién agregados.

Cuando agrego 1 producto (40 variaciones), se completa y muestra la imagen del producto. Cuando agrego 6 productos (240 variaciones), recibo un error directamente en mi navegador.

Entonces, para probar aún más este problema, modifiqué mi código y lo reescribí usando ajax y agregué una barra de proceso como sistema. (Que incrementa un número para cada variación).

Después de ejecutar el código para 1 producto (con 40 variaciones), el número de proceso aumenta a 40 y muestra la imagen del producto.

Cuando ejecuto mi código para 6 productos, el número de proceso aumenta a 240, pero no muestra nada, y cuando verifico, recibe un error 504. ( jQuery.Ajaxsección de error de función)

Entonces, esto me hace pensar que la consulta se ejecuta incluso cuando se agota el tiempo de espera, pero aún no puedo estar seguro, y estoy buscando detalles detrás del error de tiempo de espera de la puerta de enlace 504 ya que no hay buena documentación al respecto.

HOY
fuente
1
Puede depender de dónde proviene el tiempo de espera de la puerta de enlace. Esta es una pregunta interesante.
Stephen Ostermiller
@StephenOstermiller agregó algunos detalles más basados ​​en su comentario.
HOY
Presumiblemente, ¿sabría si el script se completó si todos los "6 productos (240 variaciones)" se agregaron a su sitio web? ¿O es eso difícil de determinar? ¿Quizás agregar alguna funcionalidad de registro a su script?
MrWhite

Respuestas:

3

El script no dejará de ejecutarse hasta que alcance el tiempo de espera de php.

El error 504 se genera en la puerta de enlace / proxy en sí, no proviene del proceso php.

Esto se debe a que si tiene un Apache con Apache-mod-php, nunca recibirá este error, porque no hay un proxy.

Extendiendo la explicación, piense de la siguiente manera:

Tienes un proceso PHP. El proceso PHP puede ser un PHP-FPM, PHP-CGI o Apache-MOD-PHP. En este proceso, tiene un tiempo de espera (configurado en php.ini o con un ini_set).

El proxy PHP da una respuesta en el tiempo permitido (también conocido como: si tiene un set_time_limit (600), su proceso PHP puede estar ejecutándose hasta 10 minutos).

Sin relación con esta oración, puede tener otro proceso esperando esta respuesta: ese es el caso de un apache (configurado para contactar a php por cgi o fpm), un nginx, un lighthttpd y otros. Ese no es el caso de un apache configurado por apache-mod-php. Este segundo proceso tiene un nuevo tiempo de espera (proxy_timeout), configurado en la configuración de la aplicación vhost / servidor general. Es el momento en que el programa esperará una respuesta del motor de procesamiento de PHP.

La última oración se puede repetir en cada proxy / gateway.

Piensa en este escenario:

haproxy (Tiempo de espera 1) -> Nginx (Frontend / caché) (Tiempo de espera 2) -> Apache (Tiempo de espera 3) -> PHP-FPM (Tiempo de espera de PHP / set_time_limit).

Y un escenario muy simple:

Apache (con apache-mod-php) (Tiempo de espera de PHP / set_time_limit).

Cada aparición de tiempo de espera (excepto el tiempo de espera de PHP en sí) es un origen probable de un error de tiempo de espera de la puerta de enlace 504 HTTP.

Sakura Kinomoto
fuente
"si tienes un Apache con Apache-mod-php, nunca recibirás este error", ¿puedes explicar esta última oración?
MrWhite
Cuando utiliza un servidor Apache con mod-php, la ejecución la realiza el propio Apache. Debido a esto, no puede obtener un tiempo de espera 504, porque no hay ninguna puerta de enlace en el proceso. Si usa php-cgi o php-fpm, Apache / nginx / algún otro servidor web están actuando como proxy o puerta de entrada al motor de procesamiento real. Luego, aparece el error 504 cuando esta puerta de enlace no recibió una respuesta en un período de tiempo configurado.
Sakura Kinomoto
Pero, ¿no puede tener un proxy inverso Nginx frente a Apache mod-php?
MrWhite
Obviamente, pero esa no es la pregunta en sí. En este caso, nginx puede proporcionar 504, pero no Apache. La pregunta en este caso es quién, si el proxy genera el código de error 504, la ejecución desencadenada por la llamada del proxy no se detiene. En el caso de una puerta de enlace o proxy, hay al menos dos temporizadores en juego. El tiempo de espera de la comunicación proxy (en nginx, por ejemplo) y el tiempo de espera en el proceso de php.
Sakura Kinomoto
Entiendo. Pero su última oración parecería estar incompleta en ese caso, ya que implica que simplemente usando Apache-mod-php (independientemente de si hay un proxy front-end o no) evitaría este error. Supongo que lo que quieres decir es ... "si solo tienes un Apache con Apache-mod-php y sin proxy front-end (Nginx en este caso), entonces nunca recibirás este error"?
MrWhite