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