[Rio-pm] AnyEvent

[Aureliano Guedes]

Realmente, depois de ICMP flood vou fazer syn flood.

> From: tiago.peczenyj em gmail.com
> Date: Thu, 15 Mar 2012 11:21:19 -0300
> To: rio-pm em pm.org
> Subject: Re: [Rio-pm] AnyEvent
> 
> Acho que simplifiquei.
> 
> Vc pode ter cpu e memoria "tranquilos" e o gargalo ficar na camada de
> transporte se a sua aplicação for leve o suficiente para vc violentar
> as placas de rede. Não é um problema, é apenas conhecer o
> limite/gargalo/etc. Ai vc troca a placa ou adiciona mais uma e testa
> novamente ate que outro problema surja.
> 
> Ai vc pode descobrir que quem programou as rotinas multithread para
> suportar multiplas conexões simultâneas aprendeu a programar em C++ em
> 21 dias com um livro safado e escolhe se vai xingar muito no twitter
> ou usar outra coisa.
> 
> Ah, falei syn flood pois me lembrei disso na hora :)
> 
> On Thu, Mar 15, 2012 at 11:15 AM, Stanislaw Pusep <creaktive em gmail.com> wrote:
> > Thiago: sim, na camada da aplicação, CPU quase certamente será o gargalo
> > (vide C10k problem). Mas na camada de transporte?!
> > Aureliano: Win95 *sem Service Pack* "morre" pelo WinNuke, que consiste de um
> > pacote TCP com flag Out-Of-Band para a porta 139 :)
> > Aliás, SYN flood é BEM diferente de ICMP flood; é exploit de protocolo, não
> > por "força bruta".
> >
> > ABS()
> >
> >
> >
> >
> > On Thu, Mar 15, 2012 at 11:08, Tiago Peczenyj <tiago.peczenyj em gmail.com>
> > wrote:
> >>
> >> Depende da aplicação ou infra-estrutura.
> >>
> >> Uma versão antiga do servidor de streaming de video da adobe tinha CPU
> >> como gargalo, não chegava a usar 70% das placadas de rede disponiveis,
> >> isso foi corrigido nas mais recentes. Mas isso é facilmente explicado:
> >> primeiro foi desenvolvida a versão para windows, depois foi portado
> >> para linux (que foi objeto de testes).
> >>
> >> Hoje com 2 placas 10 gigabits o cenário mudou de novo: existe alguma
> >> limitação interna que num dado numero x de pessoas conectadas o
> >> sistema começa a degenerar qualidade e rejeita clientes novos. Ainda
> >> estamos investigando porém isso não é critico (por incrivel que
> >> pareça). Uma suspeita é a forma como os processos se comunicam entre
> >> si, mas como é um produto fechado só resta sentar e esperar.
> >>
> >> On Thu, Mar 15, 2012 at 11:00 AM, Stanislaw Pusep <creaktive em gmail.com>
> >> wrote:
> >> >> Realmente acho que a rede dificilmente seria o gargalo, logo vou me
> >> >> concentrar na memoria e no CPU.
> >> >
> >> >
> >> > Neste ponto, você está MUITO errado.
> >> >
> >> > _______________________________________________
> >> > Rio-pm mailing list
> >> > Rio-pm em pm.org
> >> > http://mail.pm.org/mailman/listinfo/rio-pm
> >>
> >>
> >>
> >> --
> >> Tiago B. Peczenyj
> >> Linux User #405772
> >>
> >> http://pacman.blog.br
> >> _______________________________________________
> >> Rio-pm mailing list
> >> Rio-pm em pm.org
> >> http://mail.pm.org/mailman/listinfo/rio-pm
> >
> >
> >
> > _______________________________________________
> > Rio-pm mailing list
> > Rio-pm em pm.org
> > http://mail.pm.org/mailman/listinfo/rio-pm
> 
> 
> 
> -- 
> Tiago B. Peczenyj
> Linux User #405772
> 
> http://pacman.blog.br
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
 		 	   		  
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120315/7cf3db44/attachment.html>