Dae gurizada,A ideia de olhar para esse problema surgiu depois que o Diego Pacheco me deu a missao de falar sobre Deft e Loft em um lighting talk que fizemos ha algumas semanas atras.O grande impecilio que tive para entender o conceito dos servidores Deft e Loft foi de entender o problema. Eis a motivacao do post.O que vou tentar explicar sao as limitacoes existetes que fazem com alguns servidores nao consigam processar mais que 10mil requisicoes simultaneas. E (se tudo der certo) voce vai entender porque servidors como Deft, Loft, Tornado, Netty, Node.js e outros tem um desempenho diferente que os sservidores normais. C10k ProblemC10k significa 10.000 (dez mil) conexoes simultaneas. Este e a limitacao de conexoes silmutaneas da maioria dos servidores de aplicacao.Isso acontece devido a forma que os servidores trabalham com cada conexao recebida.Muitas destes problemas sao ocasionaos pela forma que o servidor foi impelmentado e de como o Sistema Operaciona (OS) trabalha com sockets.Eu vou descrever algumas destas limitacoes abaixo.Analise de um servidorQuem ja trabalhou com Sockets em Java, ja devem ter visto esse codigo:...ServerSocket welcomeSocket = new ServerSocket(8080);while(true){ Socket connectionSocket = welcomeSocket.accept(); ...}...Codigo simples, abre um socket na porta 8080 e fica esperando conexoes.Basicamente isso e que os servidores web fazem. E obvio que eles trabalham de uma forma mais complexa envolvendo threads, alocacoes de recursos, etc.Seguindo no nosso exemplo simples, poderiamos criar uma thread para processar cada requsicao. Fazendo assim que o servidor esteja disponivel para aceitar (accept()) uma nova conexao....ServerSocket welcomeSocket = new ServerSocket(6789);while(true){ Socket connectionSocket = welcomeSocket.accept(); final new Thread(new Runnable() { @Override public void run() { //do anything } }).start();...Nesa forma por exemplo, vamos criar diversar thread para atender as requisicoes dos clientes. Na perspetiva do SO, temos uma Thread em nivel de SO e varias threads na JVM.Alem dessas threads que estamos criando, o sitema operacional tambem exerce um tipo de controle sobre as conexoes abertas. Cada cliente e um "flie descriptor" aberto no SO.O importante aqui e entender que cada accept() vai gerar um file descriptor novo.File Descriptor (FD)?O SO tem o chamado "file descriptor" que basicamente e cada processo (socket, arquivo, fila, etc) existente no SO. Isso inclui processos ativos e "em espera" (waiting).Existe um limite de open files que o sistema operacional consegue gerenciar. Por esse motivo utilizar uma thread para cada cliente pode ser tornar um problema, pois ira consumir uma quantidade consideravel de recusros.OBS: Calma! Nao e qualquer sistema que precisa se preocupar com isso. Tudo depende da "Frequencia" de acessos e do "Volume" de dados ... ;)O Peso de ter muitos processosNao vou entrar muito afundo nesse ponto, mas a explicacao simples e: ter muitos processos abertos CUSTA CARO para o SO.Obvio, quanto mais processos mais dificil vai ser o trabalho do escalonador do OS.Todos esperando sua hora de entrar... Alem disso, temos o consumo de memoria. Quando mais processos mais memoria e... voce sabeOut of memory... Essa apresentacao fala muito bem sobre isso: http://bulk.fefe.de/scalable-networking.pdfBlocking e Non-blocking I/OSeguindo os conceitos importantes de entender e o Blocking e Non-blocking I/O.Imagine uma conexao com um servidor, onde e