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 <[email protected]>: >> 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 >> [email protected] >> 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 [email protected] 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
