Tempo limite do proxy do Apache2

18

Eu tenho o Apache2 com PHP + PHP-FPM configurado de acordo com:

link

Estou escrevendo um script que levará muito tempo para ser executado em um Vhost interno, mas continue sendo expirado, tudo será executado sem falhas se o script for executado em menos de 30 segundos.

Meu log do apache diz:

[Wed Apr 17 21:57:23.075175 2013] [proxy_fcgi:error] [pid 9263:tid 140530454267648] (70007)The timeout specified has expired: [client 58.169.202.172:49017] AH01075: Error dispatching request to :, referer:

Ao tentar executar o script, recebo um 503 Service Unavailable após exatamente 30 segundos de tempo de execução. Logicamente, isso significaria que eu tenho uma diretiva de tempo limite ou configuração definida para 30 segundos, mas eu tenho isso na configuração do meu Vhost:

Timeout 600
<IfModule proxy_module>
    ProxyPassMatch ^/(.*\.php)$ fcgi://127.0.0.1:9001/home/pyrokinetiq/scripts/$1 timeout=600
    ProxyTimeout 600
</IfModule>

(o php-fpm está rodando na porta 9001 para mim)

Eu também tentei colocar o Timeout e o ProxyTimeout em httpd.conf sem diferença.

Parece que há outra configuração de tempo limite específica em mod_proxy_fcgi , mas não consigo encontrá-lo. Eu instalei o Apache2 httpd do tarball oficial, nenhum dos mods parece ter vindo com qualquer arquivo de configuração.

Se alguém puder me apontar na direção certa, será muito apreciado.

    
por wyqydsyq 18.04.2013 / 07:11

7 respostas

26

Eu finalmente consertei esse problema depois de testar vários parâmetros de configuração. Eu testei a solução duas vezes, removendo todas as alterações anteriores. Apenas um parâmetro foi necessário para eu corrigi-lo.

Para as versões mais recentes do httpd e do mod_proxy_fcgi, basta adicionar timeout= ao final da linha ProxyPassMatch , por exemplo:

ProxyPassMatch ^/(.+\.php.*)$ fcgi://127.0.0.1:9000/<docroot>/$1 timeout=1800

Para versões mais antigas, foi um pouco mais complicado, por exemplo:

<Proxy fcgi://127.0.0.1:9000>
  ProxySet timeout=1800
</Proxy>
ProxyPassMatch ^/(.+\.php.*)$ fcgi://127.0.0.1:9000/<docroot>/$1

Eu precisava adicionar a diretiva Proxy para definir o tempo limite para 30 minutos. Em alguns aplicativos, geralmente ao operar o banco de dados, existem rotinas que podem levar mais de 10 minutos para serem executadas. Eu temporário definir o tempo limite para 30 minutos para garantir que eles terminem. Especificamente útil ao usar o assistente de instalação, o que leva muito tempo (na minha humilde opinião).

A propósito, a entrada inicial que me ajudou a resolver este problema foi encontrada no seguinte endereço de URL .

    
por 08.05.2013 / 12:10
8

Eu queria ressaltar que, embora essa resposta funcione muito bem para versões mais antigas, ela é interrompida em versões recentes do Apache 2.4 com o código de erro AH00526. ProxyPass e ProxyPassMatch ou <Proxy> e <ProxyMatch> não podem ser usados juntos com o mesmo nome de trabalhador. Isso costumava funcionar muito bem, então não sei se isso foi alterado por design ou se é um bug.

De qualquer forma, você pode corrigir isso usando apenas um ProxyPassMatch com o parâmetro 'timeout = 120' (ou qualquer que seja seu valor desejado), por exemplo:

ProxyPassMatch ^/(.*\.php)$ fcgi://127.0.0.1:9001/path/to/webroot/$1 timeout=120
    
por 11.06.2015 / 02:53
6

Eu tenho o Apache 2.4.6, mas o patch para corrigi-lo é fornecido no Apache > = 2.4.8. A chave aqui é iniciar sua saída imediatamente para que o Apache (mod_proxy_fcgi) ache que a conexão está ativa.

Por exemplo, estou usando PHP e a consulta DB para minhas chamadas de chamada AJAX > 30 segundos. Como sei que a resposta geral será "Content-Type: application / json", envio esse cabeçalho imediatamente.

#1: Start output immediately
#Note: Sending the header is innocuous
#   it can be changed later using the $replace parameter
#   (see #3)
header( 'Content-Type: application/json' );

#2: Run slow query
mysql_query( "SELECT * FROM giant_table" );

#3: Change header as needed
header( 'Content-Type: application/csv', true );

#output content
    
por 05.01.2016 / 05:53
2

Não deveria ser assim:

<IfModule mod_proxy.c>

Certifique-se de que a configuração max_execution_time do php.ini esteja configurada para 600 também. (cheque o phpinfo () na página ao vivo para ter certeza de que você está vendo o valor real usado)

Como Jenny disse, defina a configuração do php-fpm

request_terminate_timeout 610s

(observe os s no final)

Não há muito para configurar com o próprio mod_proxy_fcgi, como você pode ver na página do apache. link

Ative o registro de depuração do php-fpm também para que você possa ver onde está o tempo limite. link (também liga o catch_workers_output)

E ative o registro em nível de depuração para os módulos mod_proxy e mod_proxy_fcgi desde que você esteja usando o apache 2.4. Muito bom recurso, ligue apenas para os módulos que você precisa: link

Se isso não ajudar, poste seu arquivo de configuração do php-fpm.

Como último recurso, talvez algum daemon esteja matando o processo de execução demorada?

    
por 19.04.2013 / 05:08
2

Eu notei que você está usando o PHP-FPM. Eu também uso, mas com o Apache 2.4.6.

Supondo que o problema já existe há algum tempo, parece que o valor de tempo limite para mod_proxy_fcgi é hard coded . Escrevi o que encontrei aqui

    
por 19.03.2014 / 22:51
1

Como você corrigiu as configurações de tempo limite no apache, esse não deveria ser o problema. O segundo lugar para procurar seria qualquer equipamento de rede, mas como você está fazendo proxy para seu próprio servidor, isso também é improvável. Portanto, o local restante para procurar é no servidor backend.

Ih o arquivo de configuração para o php-pfm, procure por

; This is a hard kill switch on php execution.  It ignores the
; max_execution_time that can be set/changed with php_ini.  Basically
; it avoids timeout issues between apache and php-fpm.
request_terminate_timeout=30

Isso deve ser definido da mesma forma ou ligeiramente abaixo da configuração de tempo limite no apache.

    
por 18.04.2013 / 11:23
0

Além do tempo limite, defina enablereuse = off. Eu encontrei quando estava em alguns pedidos para scripts de longa duração funcionaria corretamente e outros seriam mortos no início.

    
por 12.05.2016 / 16:10