Quais configurações do Apache / PHP você conhece e quão boas são elas?

Question

Eu gostaria de perguntar sobre os métodos de configuração do PHP / Apache que você conhece, seus prós e contras. Eu vou começar eu mesmo:

---------------- PHP como módulo do Apache ----------------

Prós : boa velocidade, já que você não precisa iniciar o exe sempre, especialmente em mpm-worker mode. Você também pode usar vários aceleradores de PHP neste modo, como APC ou eAccelerator.

Contras : se você estiver executando o apache no modo mpm-worker, poderá enfrentar problemas de estabilidade porque cada falha em qualquer script php levará à instabilidade em todo o conjunto de encadeamentos desse processo apache. Também neste modo todos os scripts são executados em nome do usuário do apache. Isso é ruim para a segurança. A configuração do mpm-worker requer o PHP compilado no modo thread-safe. Pelo menos os repositórios padrão do Red Hat e do RedHat não possuem versões do PHP seguras para threads, então nesses sistemas operacionais você precisa compilar pelo menos o PHP (existe uma maneira de ativar o worker mpm no Apache). O uso de binários PHP seguros para thread é considerado experimental e instável. Além disso, muitas extensões PHP não suportam o modo thread-safe ou não foram bem testadas no modo thread-safe.

---------------- PHP como CGI ----------------

Esta parece ser a configuração padrão mais lenta que parece ser um "con" em si;)

---------------- PHP como CGI via mod_suphp ----------------

Prós : o suphp permite que você execute php scipts em nome do proprietário do arquivo de script. Dessa forma, você pode separar com segurança sites diferentes na mesma máquina. Além disso, o suphp permite usar diferentes arquivos php.ini por host virtual.

Contras : PHP no modo CGI significa menos desempenho. Neste modo, você não pode usar aceleradores php como o APC, porque toda vez que um novo processo é gerado, ele não funciona, tornando o cache do processo anterior inútil. BTW, você sabe o caminho para aplicar algum acelerador nesta configuração? Eu ouvi algo sobre o uso de shm para cache de bytecode php. Além disso, você não pode configurar o PHP via arquivos .htaccess neste modo. Você precisará instalar P ECL htscanner para isso se precisar definir várias opções por script via .htaccess (php_value / diretivas php_flag)

---------------- PHP como CGI via suexec ----------------

Esta configuração parece a mesma que com o suphp, mas ouvi dizer que é mais lento e menos seguro. Quase os mesmos prós e contras aplicam-se.

---------------- PHP como FastCGI ----------------

Prós : O padrão FastCGI permite que o processo de php único manipule vários scripts antes que o processo do php seja eliminado. Desta forma, você ganha desempenho, pois não há necessidade de girar o novo processo de php para cada script. Você também pode usar aceleradores PHP nesta configuração (veja a seção contras para comentários). Além disso, FCGI quase como suphp também permite que processos php sejam executados em nome de algum usuário. O mod_fcgid parece ter o suporte e a flexibilidade mais completos do fcgi para o apache.

Contras : O uso do acelerador php no modo fastcgi levará a um alto consumo de memória, pois cada processo PHP terá seu próprio cache bytecode (a menos que haja algum acelerador que possa usar memória compartilhada para o cache de bytecode Existe tal?) FastCGI também é um pouco complexo para configurar. Você precisa criar vários arquivos de configuração e fazer algumas modificações na configuração.

Parece que o fastcgi é a configuração do PHP mais estável, segura, rápida e flexível, porém um pouco difícil de ser configurado. Mas, pode ser, eu perdi alguma coisa?

Comentários são bem vindos!

    

Answer 1

Executar PHP via FastCGI certamente lhe dará mais flexibilidade. Não só você pode usar com segurança um Apache mpm-worker, você pode até mesmo usar outro servidor web (por exemplo, nginx).

Mas mesmo quando se está com o Apache, "PHP via FastCGI" não é uma opção no momento, mas pelo menos dois: mod_fastcgi, mod_fcgid. Além disso, você pode usar processos FastCGI dinâmicos, estáticos ou externos; com ou sem suexec. E então há o gerenciador de processos interno do PHP, o FastCGI, que agora é substituído pelo muito bom PHP-FPM no PHP 5.3. Todas essas opções têm diferentes prós e contras e podem levar a problemas diferentes.

Dada a escolha, eu escolheria o mod_fastcgi com o PHP-FPM no momento, principalmente porque permite configurações extremamente versáteis e estáveis.

    

Answer 2

Não respondendo realmente à sua pergunta, mas eu não entendo essa coisa sobre o FastCGI ser difícil de configurar. É diferente que os outros métodos devam ser substituídos (mod_php, mod_python, ...), portanto, pode ser necessário reescrever uma parte do código. Essa pode ser a parte difícil, mas para configurar o Apache, pelo menos, acho que é uma coisa fácil. Como exemplo, eu estava testando um aplicativo WSGI em python e queria ver como ele se comportava com todos os protocolos que o WSGI suporta. Aqui está o arquivo do host virtual com as configurações para todos os protocolos (com mod_fastcgi ):

<VirtualHost *:8888>
DocumentRoot "/home/test/"
#FastCGIExternalServer /home/test/wsgi -host 127.0.0.1:3333
#SCGIMount / 127.0.0.1:3333
FastCgiServer /home/test/wsgi/fcgi.py -idle-timeout 60 -processes 1
<Directory "/home/test/wsgi/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
    #AddHandler wsgi-script .py
    #AddHandler cgi-script .py
</Directory>
</VirtualHost>

Não parece complexo para mim. Claro, o FastCGI suporta muitas opções e pode ser ajustado à morte, mas isso é outro assunto.

Para executar é como um usuário diferente, use suexec e FastCGIWrapper , então ele se torna:

FastCGIWrapper On
<VirtualHost *:8888>
SuexecUserGroup test test
DocumentRoot "/home/test/"
FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1
<Directory "/var/www/test/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
</Directory>
</VirtualHost>

E veja este link para um arquivo php.ini personalizado, mas você deve capaz de especificá-lo com a opção -initial-env , ou seja,

FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1 -inital-env PHPRC=/blah/

    

Answer 3

Um bom candidato é: O Apache 2 ITK MPM

apache2-mpm-itk (just mpm-itk for short) is an MPM (Multi-Processing Module) for the Apache web server. mpm-itk allows you to run each of your vhost under a separate uid and gid — in short, the scripts and configuration files for one vhost no longer have to be readable for all the other vhosts.

Trabalhou muito bem para um dos nossos clientes com centenas de VirtualHosts com bastante muitos visitantes.

Você faz com que todos os profissionais executem o PHP como um módulo e resolvam algumas das desvantagens.

    

Answer 4

Para mim, a questão é qual é o propósito do servidor web. Está servindo mais de um host virtual? Nesse caso, você precisa sacrificar o desempenho para segurança isolada. Sim, o desempenho é prejudicado, mas com o hardware de hoje ainda é necessário um pouco de tráfego para trazer grandes problemas de desempenho.

Se o desempenho for tão importante, execute o site em um servidor VPS ou Dedicado e configure para desempenho.