Um script PHP para de executar quando você recebe 504 Gateway Timeout?


8

Estou em um servidor compartilhado (Siteground) e, como meu script PHP do WordPress leva mais de 30 segundos, ele retorna um tempo limite de 504 Gateway.

Minha consulta será executada e concluída se não encontrar mais um erro?

Editar: perguntei por que recebi esse erro na minha equipe de hospedagem. Aqui, o especialista em hospedagem de sites explicou o problema da seguinte maneira:

Usamos o Apache + Nginx em todos os nossos servidores. O Apache é usado para o serviço web principal, enquanto o Nginx é usado como proxy reverso e distribui o cache. Quando a resposta não pode ser veiculada no cache (geralmente, isso se refere ao conteúdo dinâmico), uma solicitação do Nginx é feita para o Apache. Quando o Apache está processando a solicitação, a encaminha para o seu site e de acordo com a lógica do PHP, as consultas MySQL podem ser feitas ou outros dados obtidos. Quando esse processo demorar muito e o Apache não retornar a resposta em tempo hábil ao Nginx, você verá esse erro. Em resumo, o Apache não pode atender à solicitação, pois o aplicativo concluiu o processo dentro do tempo permitido. Isso também significa que o processo iniciado provavelmente não foi concluído completamente e alguns dados / ações podem ter sido salvos / executados.

O especialista diz que "initiated process most probably not completed fully",

Mais detalhes no meu cenário: Meu script adiciona produtos de woocommerce com variações usando o wp_insert_postmétodo ao meu site wordpress. Após a adição dos produtos, ele exibe as imagens dos produtos adicionados recentemente.

Quando adiciono 1 produto (40 variações), ele conclui e exibe a imagem do produto. Quando adiciono 6 produtos (240 variações), recebo um erro diretamente no meu navegador.

Portanto, para testar ainda mais esse problema, modifiquei meu código e o reescrevi usando ajax e adicionei uma barra de processo como o sistema. (Que incrementa um número para cada variação).

Depois de executar o código de 1 produto (com 40 variações), o número do processo aumenta para 40 e ele exibe a imagem do produto.

Quando executo meu código para 6 produtos, o número do processo aumenta para 240, mas ele não exibe nada e, quando verifico, recebe um erro 504. ( jQuery.Ajaxseção de erro de função)

Portanto, isso me faz pensar que a consulta é executada até o tempo limite, mas ainda não consigo ter certeza e procurando detalhes por trás do erro de tempo limite do gateway 504, pois não há uma boa documentação sobre isso.


11
Pode depender de onde vem o tempo limite do gateway. Esta é uma pergunta interessante.
Stephen Ostermiller

O @StephenOstermiller adicionou mais alguns detalhes com base no seu comentário.
HOY

Presumivelmente, você saberia se o script foi concluído se todos os "6 produtos (240 variações)" foram adicionados ao seu site? Ou isso é difícil de determinar? Talvez adicione alguma funcionalidade de log ao seu script?
MrWhite

Respostas:


3

O script não para de executar até que eles atinjam o tempo limite do php.

O erro 504 é gerado no próprio gateway / proxy, não é proveniente do processo php.

É porque isso, se você possui um Apache com Apache-mod-php, nunca receberá esse erro, porque não há um proxy.

Estendendo a explicação, pense da seguinte maneira:

Você tem um processo PHP. O processo PHP pode ser um PHP-FPM, PHP-CGI ou Apache-MOD-PHP. Nesse processo, você tem um tempo limite (configurado no php.ini ou com um ini_set).

O proxy PHP fornece uma resposta no tempo permitido (também conhecido como: se você tiver um set_time_limit (600), seu processo PHP poderá estar em execução por até 10 minutos).

Sem relação com essa frase, você pode ter outro processo aguardando a resposta: É o caso de um apache (configurado para entrar em contato com o php por cgi ou fpm), um nginx, um lighthttpd e outros. Não é o caso de um apache configurado pelo apache-mod-php. Este segundo processo, possui um novo tempo limite (proxy_timeout), configurado na configuração do aplicativo vhost / general server. Esse é o tempo que o programa aguardará uma resposta do mecanismo de processamento PHP.

A última frase pode ser repetida em cada proxy / gateway.

Pense neste cenário:

haproxy (Timeout 1) -> Nginx (Frontend / cache) (Timeout 2) -> Apache (Timeout 3) -> PHP-FPM (PHP Timeout / set_time_limit).

E um cenário muito simples:

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

Cada aparência de tempo limite (exceto o próprio PHP Timeout) é uma origem provável de um erro de tempo limite do gateway HTTP 504.


"se você possui um Apache com Apache-mod-php, nunca receberá este erro" - pode explicar esta última frase?
MrWhite

Quando você usa um servidor Apache com mod-php, a execução é feita pelo próprio Apache. Por isso, não é possível obter um tempo limite de 504, porque não há nenhum gateway no processo. Se você usa php-cgi ou php-fpm, o Apache / nginx / algum outro servidor da web está agindo como proxy ou gateway para o mecanismo de processamento real. Em seguida, o erro 504 aparece quando esse gateway não recebe uma resposta em um período configurado.
Sakura Kinomoto

Mas você não pode ter um proxy reverso Nginx na frente do Apache mod-php?
MrWhite

Obviamente, mas essa não é a questão em si. Nesse caso, 504 pode ser fornecido pelo nginx, mas não pelo Apache. A questão nesse caso é: quem, se o código de erro 504 for gerado pelo proxy, a execução acionada pela chamada do proxy não será interrompida. No caso de um gateway ou proxy, há pelo menos dois temporizadores em jogo. O tempo limite da comunicação de proxy (no nginx, por exemplo) e o tempo limite no processo php.
Sakura Kinomoto

Compreendo. Mas sua última frase parece incompleta nesse caso, pois implica que o simples uso do Apache-mod-php (independentemente de haver ou não um proxy de front-end) evitaria esse erro. Eu assumo o que você quer dizer é ... "se você tiver apenas um Apache com Apache-mod-php e nenhum proxy front-end (Nginx neste caso), nunca receberá esse erro"?
precisa saber é o seguinte

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.