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

Leonardo Augusto lalinden em gmail.com
Terça Dezembro 16 13:32:49 BRST 2008 

E ai Patrick,

É vou fazer isso mesmo.

php+mysql vou usar o apache+dso, num ip/porta

e vou por o lighttpd num jail pq preciso que roda na mesma porta 80,
pode ser outro dominio tipo www2, mas nao da pra ser outra porta,
pq muitos lugares so permitem acesso na porta 80..

E esse mode rewrite deve consumir uma instancia do apache se ele fizer tipo
o "bounce" do bsd.., acho que fica melhor o request chegar direto no lighttpd.

Fiz uns testes com o ab, mas sempre da um erro escroto...


server64# ab -q -c 5 -n 500 http://74.xxx.144.114/teste.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 74.86.144.114 (be patient)...Send request failed!
Send request failed!
Send request failed!
apr_socket_recv: Connection reset by peer (54)
Total of 6 requests completed

se rodo so com uma conexao tambem da erro

server64# ab -q -c 1 -n 500 http://74.xxx.144.114/teste.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 74.86.144.114 (be patient)...apr_socket_recv: Connection
reset by peer (54)


eheheh oganza bizaza isso.

[]'s




2008/12/16 Patrick Tracanelli <eksffa em freebsdbrasil.com.br>:
> 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!"
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>

Mais detalhes sobre a lista de discussão freebsd