Quais configurações do Apache / PHP você conhece e qual a sua qualidade?

Eu queria perguntar sobre os métodos de configuração do PHP / Apache, seus prós e contras. Eu vou me começar:

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

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

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

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

Essa parece ser a configuração padrão mais lenta que parece ser um "contra";)

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

Prós : o suphp permite executar php scipts em nome do proprietário do arquivo de script. Dessa forma, você pode separar com segurança diferentes sites 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. Nesse modo, você não pode usar aceleradores php como o APC, porque cada vez que um novo processo é gerado para lidar com scripts, torna inútil o cache do processo anterior. BTW, você sabe como aplicar algum acelerador nesta configuração? 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 o P ECL htscanner para isso se precisar definir várias opções por script via .htaccess (diretivas php_value / php_flag)

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

Essa configuração é igual à do suphp, mas ouvi dizer que é mais lenta e menos segura. Quase os mesmos prós e contras se aplicam.

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

Prós : O padrão FastCGI permite que um processo php único processe vários scripts antes que o processo php seja eliminado. Dessa forma, você obtém desempenho, pois não é necessário criar um novo processo php para cada script. Você também pode usar aceleradores PHP nesta configuração (consulte a seção contras para comentar). Além disso, o FCGI quase como o suphp também permite que processos php sejam executados em nome de algum usuário. O mod_fcgid parece ter o mais completo suporte e flexibilidade 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 de bytecode (a menos que exista algum acelerador que possa usar a memória compartilhada para o cache de bytecode. Existe?). O FastCGI também é um pouco complexo de configurar. Você precisa criar vários arquivos de configuração e fazer algumas modificações na configuração.

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

Comentários são bem-vindos!

Executar o PHP via FastCGI certamente lhe dará a maior flexibilidade. Você não apenas pode usar com segurança um Apache mpm-worker, como também pode usar outro servidor da Web (por exemplo, nginx).

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

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

Não estou realmente respondendo à sua pergunta, mas não entendo o fato de o FastCGI ser difícil de configurar. É diferente dos outros métodos que ele deve substituir (mod_php, mod_python, ...), portanto, pode ser necessário reescrever uma parte do código. Essa pode ser a parte mais 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 funcionava com todos os protocolos que o WSGI suporta. Aqui está o arquivo do host virtual com as configurações de 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 me parece complexo. Claro, o FastCGI suporta muitas opções e pode ser ajustado até a morte, mas isso é outra questão.

Para executar é como um usuário diferente, use suexec e FastCGIWrapper, em seguida, 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 php.ini personalizado, mas você deve poder especificá-lo com a -initial-envopção

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

Um bom candidato é: O Apache 2 ITK MPM

O apache2-mpm-itk (apenas mpm-itk) é um MPM (Multi-Processing Module) para o servidor da web Apache. O mpm-itk permite que você execute cada um dos seus vhost sob um uid e gid separados - em resumo, os scripts e arquivos de configuração de um vhost não precisam mais ser legíveis para todos os outros vhosts.

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

Você obtém todos os profissionais executando o PHP como um módulo e resolve alguns dos contras.

Para mim, a questão é qual é o objetivo do servidor web. Está servindo mais de um host virtual? Nesse caso, você precisa sacrificar o desempenho por segurança isolada. Sim, o desempenho sofre, mas com o hardware atual, ainda é preciso 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.