lighttpd + resposta lenta de PHP-fcgi

Question

Nós temos um problema em relação ao lighttpd como o servidor web com o php5 como backend via fast-cgi. Às vezes, a resposta do servidor leva mais de 5 segundos (até 20 segundos) ao solicitar um arquivo simples que chama phpinfo(); . O log do servidor não mostra nenhum erro e a resposta HTTP é de 200.

Quando eu solicito um arquivo estático html sem qualquer conteúdo PHP, não há problema e todas as solicitações estão sendo atendidas rapidamente.

Esta é a configuração do lighttpd-fcgi:

fastcgi.debug = 1
fastcgi.server += ( ".php" =>
    ((
        "bin-path" => "/usr/bin/php-cgi",
        "socket" => "/tmp/php.socket",
        "max-procs" => 7,
        "bin-environment" => (
            "PHP_FCGI_CHILDREN" => "5",
            "PHP_FCGI_MAX_REQUESTS" => "5000"
        )
    ))
)

O servidor está executando o Debian 7 de 64 bits.

    

Answer 1

Verifique se você não tem manipuladores de fcgi órfãos, a maneira mais fácil é parar o lighttpd e depois 'ps auX' e procurar por php-cgi. Mate-os se existir algum, então comece de novo.

Configure um manipulador de status do servidor em sua configuração lighty. Isso permitirá que você atualize uma página e veja todas as conexões sendo tratadas atualmente e em que estado elas estão. link

Verifique se lighty realmente pode gravar em seu log de erros. Ao parar e reiniciar, deve deixar um log em error.log. Desta forma, se seus manipuladores fcgi estão todos amarrados e lighty tem que parar um pedido, isso será registrado.

Eu não recomendaria max-procs = > 7 a menos que você tenha uma boa razão para isso. Tente abaixar o max-procs para 1 e aumentar seu FCGI_CHILDREN significativamente. Meu servidor de alto tráfego está configurado para usar o max-procs 1 e o FCGI_CHILDREN 120. Eu percebo que isso contradiz o wiki lighttpd, no entanto, que é editado pelos usuários, enquanto minha sugestão é baseada em evidências empíricas e também conselhos diretamente do time lighty.

A outra coisa a ter em mente é que há um cache de opcode separado sendo mantido para o processo each . Então, reduzindo-o para 1, todos os scripts estão usando o mesmo cache opcode, o que significa menos tempo gasto na compilação e remoção de 7 caches diferentes.

    

Answer 2

Cada processo de trabalho do php pode manipular apenas uma solicitação de cada vez; cada "proc" (no seu caso 7) geralmente tem um processo mestre (que não lida com pedidos) e PHP_FCGI_CHILDREN (no seu caso 5), que perfaz um total de 35 processos de trabalho.

lighttpd aloca um soquete separado para cada "proc", e cada soquete tem sua própria fila de pedidos. Portanto, se levar muito tempo para processar sua solicitação, é muito provável que o back-end selecionado tenha uma longa fila de solicitações para lidar.

Portanto, basta fazer algumas contas simples: se uma solicitação levar php por aproximadamente 2 segundos, sua configuração pode manipular #workercount / #timeperrequest = 17.5 requests / sec.

Para aumentar o número de solicitações por segundo, você tem duas opções:

• inicie mais processos de trabalho do php (e certifique-se de ter memória / CPU suficiente para serem executados, assista top e outras ferramentas)
• melhora o tempo de resposta de solicitações únicas (procure consultas SQL lentas, solicitações http para serviços internos, ...); verifique novamente se há gargalos de memória e CPU com top - se o seu servidor iniciar a troca, tudo ficará lento.

PS: não coloque seus sockets em /tmp ; coloque-os em (/var)/run/lighttpd/ e certifique-se que apenas o seu usuário lighttpd ( www-data ) tenha acesso, veja CVE-2013-1427