O paradigma C10k

Esse termo foi criado por Dan Kegel em seu site que dizia basicamente o seguinte: a Internet é um lugar grande, e já é hora de tratar 10.000 requisições simultâneas. Há 10 anos atrás, sites como o cdrom.com, alguns dos mais acessados da Internet, respondia em torno de 10.000 requisições simultâneas utilizando-se de uma placa ethernet Gigabit. Esse número já se tornou bastante comum em alguns provedores, e precisamos aprender a lidar com ele.

Todo o problema parte da análise de sistemas operacionais e suas estratégias para tratamento de requisições simultâneas. O problema foi muito bem abordado por Felix von Leitner em Outubro de 2003, quando conseguiu mostrar que o kernel 2.6 era realmente mais rápido que o 2.4, e um trabalho bastante didático pode ser encontrado nessa tese de mestrado, que também analisa os vários aspectos que afetam a performance no SO. É importante para todo o administrador de sistemas (sysadmin) entender as diferentes abordagens dos mecanismos de entrada/saída (I/O) para obter a melhor solução para o seu problema.

Algumas opções para os desenvolvedores de software para a Internet:

  • Utilizar ou não muitas chamadas de I/O numa única thread:
    • Não. Utilize chamadas completamente síncronas/bloqueantes, e utilize múltiplos processos para tratar a concorrência. Uma chamda bloqueante é aquela que trava a fila até que seja completada.
    • Utiliza chamadas não bloqueantes (Ex.: write() num socket ajusta para O_NONBLOCK) para iniciar o I/O, e notificações de término (como poll() ou /dev/poll) para descobrir quando aquele canal estará livre para iniciar a próxima I/O. Normalmente só é possível utilizar essa estratégia com I/O de rede, não de disco.
    • Utiliza chamadas assíncronas (Ex.: aio_write()) para iniciar a I/O, e a notificação de término (como sinais e portas de aviso) para saber quando a operação de I/O terminou. Pode ser usado tanto em I/O  de disco como de rede.
  • Como controlar o código entregue a cada cliente:
    • um processo para cada cliente (abordagem padrão do Unix)
    • uma thread do SO controla vários clientes; cada cliente é controlado por:
      • uma thread no nível do usuário (Ex.: threads de estado do GNU, Java com suas threads verdes)
      • uma máquina de estados (um pouco diferente, mas popular em alguns círculos)
      • uma continuação (também diferente, mas popular em alguns círculos)
    • uma thread do SO para cada cliente (Java com suas threads nativas)
    • uma thread do SO para cada cliente ativo (Tomcat com o frontend do Apache; ports de completude do NT; pools de thread; AOLServer)
  • Quando utilizar o serviços padrão do SO, ou quando embutir parte do código no Kernel (Ex.: um driver customizado, um módulo do Kernel, etc.)

As cinco combinações a seguir parecem ser as mais populares:

  1. Atender muitos clientes com cada thread, utilizar notificações de término acionadas por gatilhos de nível e I/O não bloqueante
  2. Atenter muitos clientes com cada thread, utilizar notificações de alteração de estado e I/O não bloqueante
  3. Atender muitos clientes com cada thread do servidor, utilizando I/O assíncrona
  4. Atender um cliente com cada thread do servidor, utilizando I/O bloqueante
  5. Colocar o código do servidor no kernel

Cada uma das abordagens possui vantagens e desvantagens, sendo mais ou menos performáticas para determinados casos. O maior gargalo normalmente encontra-se nos dispositivos utilizados pelo SO para iniciar e terminar um novo processo/thread, e a estratégia de I/O que bloqueia ou não a entrada de novos processos. Em servidores rodando Linux,a implementação não completa das threads me faz acreditar que a opção 4 acaba sendo mais rápido, e consequentemente os servidores que a adotam. E você? Qual a sua opinião?

Fonte: Site do Dan Kegel

0saves


Se você gostou desse post, deixe um comentário ou inscreva-se no feed RSS para ter todas os posts enviados para o seu agregador preferido.

Author Description

Eduardo Santos

Mestre em Computação Aplicada pela Universidade de Brasília (UnB), Tecnologista na Agência Espacial Brasileira, professor do Uniceub e cientista de dados (data scientist).

No comments yet.

Leave a Reply

Twitter

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 504 other subscribers

Alguns direitos reservados

Licença Creative Commons
Este trabalho está licenciado com uma Licença Creative Commons - Atribuição-NãoComercial 4.0 Internacional.