Problemas de Performance

[Bráulio Bhavamitra]

Conversando hoje com Daniela sobre performance, ela disse sobre o impacto
da versão 0.43 em performance.

No CIRANDAS, temos uma boa estabilidade de performance depois de mexer
basicamente em duas coisas:
1) Mudar para o REE, que é por volta de 30% mais rápido que o MRI e não
"vaza memória", ou seja, a performance se mantém com o tempo.
2) No entanto, a cpu ainda continuava altíssima, por volta dos 100% da
máquina. A solução foi bater de frente com os bots:
# put some bots in one proxy port
RewriteCond %{HTTP_USER_AGENT}
(?:Googlebot|Googlebot|bing|Mediapartners|Adsbot|Feedfetcher)-?(?:Google|Image)?
[NC]
RewriteRule ^.*$ http://localhost:50003%{REQUEST_URI} [P,QSA]
# deny other bots
RewriteCond %{HTTP_USER_AGENT} baidu [NC,OR]
RewriteCond %{HTTP_USER_AGENT} bot [NC]
RewriteRule ^.*$ - [F]

A configuração no apache acima bloqueia quase todos os bots a não ser os
mais famosos. Além disso, para os bots permitidos, dá direito que acessem
apenas um dos 4 servidores thin (na porta 50003).
O bot chines baidu foi o que mais perturbava.
Com isso a CPU voltou a níveis baixos, menor que 50%, muitas vezes menor
que 20%.

Aliás, gostaria de parabenizar o trabalho feito na 0.43. Ficou muito boa a
estrutura modular para as buscas.

abraços,
bráulio



2013/5/16 Bráulio Bhavamitra <brauliobhavamitra at gmail.com>

> Oi rodrigo e demais,
>
> Há tempo fiquei de responder e só agora encontrei a disposição.
>
> Em primeiro lugar, acho muito bom que se invista em mais estrutura para
> encontrar
> problemas antes que eles entrem em produção. Isto vai ajudar muito com
> problemas
> gerais, mas receio que neste caso não ajude muito...
>
> O problema de "vazamento" de memória, como identificado por vocês, está no
> ruby 1.8. A turma do twitter
> teve este problema há muito tempo, e por isso decidiu mudar para o REE
> (ruby compatível com o ruby mri 1.8)
> Vejam os posts abaixo:
>
> http://engineering.twitter.com/2011/03/building-faster-ruby-garbage-collector.html
> http://engineering.twitter.com/2011/05/faster-ruby-kiji-update.html
>
> Por isso, temo que investir numa estrutura de homologação possa atrasar
> mais ainda a correção
> do problema, que envolve a atualização do noosfero para um ruby
> aperfeiçoado (1.9 ou ree).
>
> abraços,
> bráulio
>
>
>
>
> 2013/3/14 Rodrigo Souto <rodrigo at colivre.coop.br>
>
>>  Olá pessoal,
>>
>> Há algumas versões o Noosfero têm apresentado um problema recorrente de
>> performance em praticamente todas as suas instalações de produção. Após
>> realizarmos o monitoramento e investigação dessas redes, diagnosticamos
>> o problema como sendo, principalmente, vazamento de memória. Esse
>> problema é agravado pelo fato de ainda estarmos utilizando Ruby 1.8; é
>> de conhecimento geral que o gerenciamento de memória na máquina virtual
>> do Ruby 1.8 é deficiente, o que foi corrigido na versão 1.9.
>>
>> Esse diagnóstico explica e confirma o porquê do comportamento sugerido e
>> aplicado por nós de reiniciar os servidores do Noosfero periodicamente
>> tem "funcionado" por enquanto.
>>
>> Uma vez diagnosticado o problema, passamos a fazer a investigação das
>> suas causas e, dada urgência da questão, demos foco a uma solução mais
>> veloz e direta (essa investigação está registrada aqui:
>> http://noosfero.org/Development/ActionItem2569). Porém, essa
>> investigação se mostrou parcialmente infrutífera uma vez que os
>> problemas com os quais nós estamos lidando estão diretamente
>> relacionados com a realidade dos servidores de producão, com todos os
>> seus dados, configurações e cargas de acesso reais.
>>
>> Tendo em vista o nível de urgência do problema, a inviabilidade de
>> investigação em ambientes de teste ou desenvolvimento e um longo
>> interesse nosso em melhorar a qualidade do desenvolvimento do Noosfero
>> como um todo, tomamos a decisão de investir nossos esforços em uma
>> solução maior, mais trabalhosa, porém, mais completa, que servirá não só
>> para solucionarmos esse problema, mas também para prevenir que eles
>> voltem a acontecer novamente no futuro. Essa solução será,
>> majoritariamente, um aperfeiçoamento da nossa infra-estrutura,  com a
>> criação de servidores de homologação, integração continua do código e
>> testes de carga.
>>
>> Pretendemos, a partir dessa solução, ser capazes de localizar exatamente
>> os locais que estão causando este vazamento de memória e corrigirmos
>> esse problema.
>>
>> Agradeçemos a paciência de todos e saibam que nós estamos nos dedicando
>> a fundo para resolver esses problemas.
>>
>> --
>> Rodrigo Souto <rodrigo at colivre.coop.br> :: 55 71 8131-7714
>> Colivre - Cooperativa de Tecnologias Livres
>> http://www.colivre.coop.br/
>>
>> _______________________________________________
>> Noosfero-br mailing list
>> Noosfero-br at listas.softwarelivre.org
>> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-br
>>
>>
>


-- 
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
http://cirandas.net/brauliobo
http://eita.org.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20130627/5ace3d93/attachment-0001.html>