[FUG-BR] Apache22+php5 - mod_php ou fastcgi ?

Terça Dezembro 16 13:09:06 BRST 2008

Leonardo Augusto escreveu:
> Ola Patrick..
> 
> Pois é... tudo que voce disse faz sentido..
> A minha duvida entre os dois modos de operacao se deu no seguinte sentido..

Ola Leonardo,

> 
> apache+php via fastcgi:
> -------------------------------------------
> pelo que entendi, e quando rodei nessa configuracao eu vi, que ficam
> varios php-cgi startados..

Perfeito, na verdade um php-cgi para cada instância simultânea que 
chegou a acontecer.

> aí quando chega um request que lida com php, o apache comunica direto
> com um desses

Exato, um monte de syscall passando o arquivo de uma aplicacão pra outra 
via socket local.

> processos cgi que ja estao rodando, via o fastcgi..
> Li que isso teria vantagens quando alem de php o site trata muito
> arquivo estatico, o que seria

Na verdade não da pra ter vantagem tecnicamente. Ao inves de termos uma 
aplicacao que ja sabe como processar, associando a extensao a um handler 
interno que sabe o que fazer, temos na verdade uma aplicacao que associa 
a extensao a um handler que nao sabe o que fazer so sabe que tem que 
passar pra um socket local, e esperar a resposta pronta. Nesse caso o 
trabalho do Apache eh mais leve simplesmente porque ele delega o 
trabalho pesado ao CGI. Isso gera várias syscalls adicionais, e 
consequentemente overhead adicional.

Sobre estático VS dinamico da na mesma visto que a associacão de tipos é 
por extensão em ambos os casos. Quando se fala de servir estático a 
comparação deve ser Apache VS LightHTTP não Apache+PHP-FCGI VS 
Apache+PHP-DSO

> vantagem pois o apache nao teria que carrega o modphp a cada fork..

Então, funciona assim. Se tem que haver o fork de um novo child process 
sim, todos os modulos DSO sao carregados a cada fork. Sem execao. Isso 
inclui o modulo fastcgi do PHP rodando em modo fcgi. Nao faz diferenca.

A questão é que se for fast-cgi temos ainda outra questão, além dos fork 
  do apache tem ainda o fork de novos php-cgi. O Apache funciona assim, 
quando vc inicia ele inicia StartServers instancias, nesse caso cada um 
dlees ja tem o PHP em DSO carregado. Depois de StartServer+1 ele vai 
carregar MinSpareServers de uma vez, e eles teão o PHP em DSO.

Porém se você tem o PHP em FCGI os StartServers vão chamar o modulo que 
joga as requisicoes pro fastcgi, que joga sua vez pro spawn-fcgi que por 
sua vez iniciam o php-cgi. Isso acontece para cada vez que uma nova 
instancia httpd for iniciar que consuma php via fastcgi.

> tudo bem.. mas até ai poderiamos deixar como vc disse rodando pelo
> menos 512 processos do
> apache com dso e esse delay no fork nao seria problema correto ?

Correto, é possível, mas não fica acontecendo fork todo o tempo, so 
quando ha mais requisicoes simultaneas do que novos processos iniciados.

> 
> apache+php via dso
> ------------------------------------------------
> pois é, nesse caso o gargalo seria se ouvessem muitos forks atrelados
> ao grande numero de hits..
> até ai tambem se deixar uma grande quantidade de processos sempre
> startados do apache acho
> que nao deve ser problema..
> 
> Essa minha duvida surgiu em funcao de um servico que vou por no ar que
> alem de php com acesso
> a mysql, tem muito acesso a arquivos staticos de pequeno tamnho, 15K em media..

Nesse caso faça como YouTube: estatico no lighttpd e dinamico no Apache. 
Lighttpd tem até 18% mais performance pra servir arquivos estáticos.

> Entao achei que em funcao da maioris dos hits (80%) ser de arquivos
> estaticos, o dso poderia gerar
> um overhead desnecessario..

O cgi vai gerar bem mais overhead não só no startup dos processos child 
mas em toda operacão php.

> No final, acho que vou deixar o apache+php em dso para tratar a
> interacao com mysql, e vou por um jail
> noutro ip com o lighttpd apenas para suprir as paginas estaticas...
> 
> O que vc acha ?

Faz bem :D Nem precisa de Jail, o mod_rewrite resolve se voce rodar um 
webserver na 80 e outro noutra porta.

> Assim eu eliminaria o risco de o grande numero de requisicoes
> estaticas "laguear" o php<->mysql no apache..
> 
> Ou sera que nao há necessidade disso ?

Não sei qual sua expectativa de demanda em numeros de hits/s? E qual 
tipo de processamento PHP? É fácil rodar um ab fazendo bench pra testar 
isso.

> 
> Estou usando freebsd 7.1(o ultimo la) 

num dual quad core 2.66 com 8G
> de ram e um raid 10 com scsi 15k rpm.
> 
> Só quero fazer o melhor ajuste nessas apps para para nao porem a culpa
> no freebsd,
> ja que todo mundo quer usar linux e eu que opto pelo freebsd, eheh
> 
> Bom, valeu pelos comentarios Patrick.
> 
> []'s
> 
> 
> 
> 
> 
> 
> 
> 
> 2008/12/15 Patrick Tracanelli <eksffa em freebsdbrasil.com.br>:
>> Leonardo Augusto escreveu:
>>> Ola,
>>>
>>> Tenho pesquisado na net e vi alguns comentarios que o php5 tem um
>>> desempenho melhor no apache22 se for usado via mod_fastcgi..
>>> ao inves de mod_php
>>>
>>> O argumento é que o core do php nao é carregado pelo apacha a cada
>>> instancia do servidor...
>>> E para o mod_php ainda nao funciona bem com o tal do mpm.. que
>>> resolveria esse problema..
>>>
>>> É melhor entao usar o php via mod_fastcgi ?
>> Pessoalmente não sei não, não vejo sentido nisso. A grande vantagem de
>> performance do php no Apache é exatamente o modulo DSO. O que você deve
>> ter lido foram duas coisas, a performance no Apache 2.2 é menor (quando
>> comparado com Apache 2.0) e o carreamento da nova instância é mais
>> lento. Já li ambos e o primeiro fato eu não avaliei, o segundo fato não
>> faz sentido:
>>
>> - Ao invés de um novo httpd com o DSO do php, o cgi carrega um novo
>> php-cgi via spawn-fcgi; como pode ser mais rápido? Conte comigo as
>> chamadas de sistema, ao invles de 1 malloc pro DSO são um execve+fork
>> pro httpd carregar o spawn-cgi, que por sua vez faz 1 malloc+execve+fork
>> para carregar o php-cgi; em cada instância "nova";
>>
>> - Depois disso cada instrucão processada pelo PHP é enviada através de
>> socket local para o php-cgi, quee processa e devolve tambem via socket
>> para o Apache; são cerca de 4 syscalls a mais por operacão, que não
>> existe no caso do uso de módulo DSO;
>>
>> - Finalmente, se há qualquer diferenca de performance é no startup da
>> instância do servidor. Isso é problema? Aumente o MinSpareServers e vai
>> startar todos ao custo de 1 syscall de malloc por DSO e 1 syscall
>> fork/execve ao invés de várias por instância;
>>
>> - Só pode ser problema para quem usa MaxRequestsPerChild diferente de 0
>> no Apache. Ainda assim se for um valor muito baixo (tipo 2) para o
>> MaxRequestsPerChild;
>>
>> Por último, se o custo de carregar o DSO do php é tão grande, porque não
>> é com o mod_access, o mod_ssl, com WebDAV, e mais N módulos DSO
>> extremamente populares que o sistema carrega em cada instância?
>>
>> Logico, to falando com base no Apache 2.0; No 2.2. porem ainda que haja
>> mesmo essa diferenca de performance se for tão crítica ao ponto de fazer
>> uma implementacão mais pesada ficar mais rápida é um problema no mínimo
>> crucial, pq o framework de DSO do Aapche é o basico dele.
>>
>> Sei que o PHP em modo CGI tem como vantagem pode ser executado com
>> privilégio do usuário dono do script, ao invés de ser com usuário do
>> Webserver. Em ambiente compartilhado isso pode aumentar a performance;
>> por outro lado em DSO temos os php_admin_flags|value da vida
>> configuráveis por contexto; o que temos de equivalente via CGI? Trocar
>> variáveis de ambiente não serve, o programador redefine elas quando bem
>> entender.
>>
>> O fato acima só pra considerar que nem tudo é performance. Segurança na
>> minha opinião é mais critico e ai sim pode haver uma conversa
>> interessante sobre fastcgi VS DSO.
>>
>> --
>> Patrick Tracanelli
>>
>> FreeBSD Brasil LTDA.
>> Tel.: (31) 3516-0800
>> 316601 em sip.freebsdbrasil.com.br
>> http://www.freebsdbrasil.com.br
>> "Long live Hanin Elias, Kim Deal!"
>>
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"