Introduo a Programao Baseada em Eventos

Daniel de Angelis Cordeiro

Aula para a disciplina de MAC 438 Programao Concorrente

21 de junho de 2005

danielc@ime.usp.br

1/30

Ou Como evitar o uso do que aprendemos em Concorrente em busca de escalabilidade :-)

Daniel de Angelis Cordeiro
Aula para a disciplina de MAC 438 Programao Concorrente

21 de junho de 2005

danielc@ime.usp.br

2/30

Sumrio

Introduo Os 4 problemas clssicos de desempenho Arquiteturas escalveis SO e Escalabilidade Descrio do projeto Arquitetura do Quake Resultados Preliminares Plano de Trabalho
3/30

Um pouco do meu trabalho de mestrado:

danielc@ime.usp.br

Introduo

Por que no conseguimos lidar com dezenas de milhares de clientes com os computadores atuais? Se usarmos uma mquina de 1 GHz, 2 Gb de memria RAM e uma conexo Gigabit para atender 20.000 requisies simultneas, teramos 50 KHz, 100 Kbytes e 50 Kbits/s para o tratamento de cada requisio. No suficiente? Ser que exagero?

Efeito slashdot; Pgina da CNN durante 11/9 [30.000 req./s].

4/30

danielc@ime.usp.br

Os 4 arqui-inimigos do desempenho de servidores

Alocao de Memria: repetidas alocaes e desalocaes de memria podem prejudicar o desempenho. Pr-alocao ou lookaside lists (coloque os objetos que no sero utilizados em uma lista ao invs de desaloc-los e reutilize-os) resolvem o problema; Cpia de Dados: duplicao de dados dentro do programa (comum entre os programas orientados a objetos) ou entre o programa e o SO; Troca de Contexto; Conteno de locks.
5/30

danielc@ime.usp.br

Meu servidor Web

si.sin_family = PF_INET; inet_aton("127.0.0.1", &si.sin_addr); si.sin_port = htons(80); bind(fd, (struct sockaddr*)si, sizeof si); listen(fd); while ((cfd=accept(fd,(struct sockaddr*)si,sizeof si)) != -1) { read_request(cfd); /* read(cfd,...) at ler "\r\n\r\n" */ write(cfd, "200 OK HTTP/1.0\r\n\r\n" "Minha pgina vrzea.", 19+20); close(cfd); }
danielc@ime.usp.br 6/30

Meu servidor Web (II)

Parece eficiente, mas tosco! O processo pode travar nas seguintes operaes:

accept(): mas tudo bem, se travar porque no tem nenhuma requisio para atender; read(): apesar de accept() indicar que h uma requisio a ser processada, os dados podem estar incompletos; write(): bloqueia se os buffers do SO estiverem cheios.

Sem contar que o servidor no implementa o protocolo HTTP.

7/30

danielc@ime.usp.br

Arquiteturas Escalveis
Aplicaes que disponibilizam servios para um grande nmero de usurios precisam multiplexar o tratamento de diversas requisies simultaneamente. Apresentaremos algumas das arquiteturas utilizadas para tal finalidade:

Multi-process (MP); Multi-threaded (MT); Single process event-driven (SPED); Asymmetric multi-process event-driven (AMPED); Staged event-driven architecture (SEDA).
8/30

danielc@ime.usp.br

Arquitetura Multi-process

Nesta arquitetura, todas as etapas so executadas, seqencialmente, por um nico processo. Quando um processo executa uma operao bloqueante, outro processo automaticamente eleito pelo sistema operacional para usar a CPU. Como mltiplos processos podem ser utilizados (tipicamente algo entre 20 e 200 processos), requisies so atendidas simultaneamente. No necessrio realizar sincronizao entre processos. Entretanto mais difcil realizar otimizaes que dependam de memria global.
9/30

danielc@ime.usp.br

Arquitetura Multi-threaded

A arquitetura MT emprega mltiplas threads independentes que utilizam um espao de endereamento compartilhado. Cada thread executa todas as etapas de uma requisio. A diferena em relao a arquitetura MP que neste modelo mais fcil realizar otimizaes que necessitem de memria compartilhada (por exemplo, um cache de URLs vlidas em servidores web). Entretanto, necessrio utilizar controles de acesso a memria compartilhada e imprescindvel que o sistema operacional fornea suporte a threads.
10/30

danielc@ime.usp.br

Arquitetura Single-process event-driven

Utiliza um nico processo, implementado utilizando o paradigma de programao baseada em eventos.

O fluxo de execuo controlado pelos eventos ocorridos; Possui uma nica linha de execuo (no h concorrncia); No h preempo nos tratadores de eventos.

Despachante
fila de eventos

Tratadores de Eventos
11/30

danielc@ime.usp.br

Arquitetura SPED (cont.)

O servidor utiliza operaes no-bloqueantes para realizar operaes de E/S assncronas (utilizando select(), poll(), epoll(), etc.). A arquitetura SPED pode ser vista como uma mquina de estados. Em cada iterao, o servidor realiza um select() para determinar se alguma operao de E/S foi concluda e, se foi concluda, gera um novo evento que ser tratado pelo despachante de eventos. No necessita de nenhuma forma de sincronizao, mas pode apresentar problemas em SOs que no implementam operaes no-bloqueantes adequadamente.
12/30

danielc@ime.usp.br

Exemplo de servidor baseado em eventos

O exemplo clssico de implementao de um servidor baseado em eventos o servidor web. Um servidor web pode ser dividido da seguinte forma: Aceita Conexo L Requisio Encontra Arquivo

incio

Envia Cabealho

L Arquivo/ Envia Dados

fim

danielc@ime.usp.br

13/30

Vocs no ficam emocionados?

Ao ver que a arquitetura SPED mais eficiente do que a multi-threaded e, como bnus, livra os desenvolvedores (vocs, que esto se descabelando tentando implementar o melhor EP da turma) dos locks, monitores e de todos os problemas que aprendemos a resolver em Programao Concorrente?

:-)
danielc@ime.usp.br 14/30

Arquitetura Asymmetric Multi-Process Event-Driven

A arquitetura AMPED combina a abordagem baseada em eventos da arquitetura SPED com mltiplos processos (ou threads) ajudantes. Quando uma operao potencialmente bloqueante precisa ser realizada, o despachante utiliza um ajudante existente ou cria um novo. Assim que a operao termina, o ajudante notifica o despachante utilizando canal de comunicao inter-processos (ex: pipe). Idealmente o trmino do tratamento de um evento assncrono produz um novo evento.

danielc@ime.usp.br

15/30

Staged Event-Driven Architecture

A arquitetura SEDA divide um programa baseado em eventos em conjunto de estgios interligados por filas de eventos. Cada estgio composto por uma fila de eventos, um despachante de eventos e um pool de threads. Um controle de admisso de novos eventos em cada um dos estgios permite a adaptao do servidor em caso de sobrecarga. Cada estgio determina dinamicamente o tamanho mais adequado para seu pool de threads ajudantes.

danielc@ime.usp.br

16/30

SO e Escalabilidade

Historicamente os sistemas operacionais oferecem aos processos uma viso virtual dos recursos: o processo se utiliza dos recursos como se fosse o nico processo existente. Por conta disso os SOs atuais no permitem que as aplicaes influenciem as decises tomadas nos gerenciamentos de recursos escondendo das aplicaes o fato de que os recursos so limitados e compartilhados com outros processos. Vrios trabalhos visam a criao de extenses do SO para torn-lo mais adequado para a criao de aplicaes escalveis.
17/30

danielc@ime.usp.br

SO e Escalabilidade (II)
Dentre os trabalhos estudados que analisam o impacto da interao entre SO e aplicao, podemos citar:

Scheduler Activations; accept()able Strategies for Improving Web Server Performance; Lazy Asynchronous I/O for Event-Driven Servers User-level connection tracking; sendfile(); /dev/epoll; K42.
18/30

danielc@ime.usp.br

E a, vamos falar de joguinhos?

danielc@ime.usp.br

19/30

Motivao

Redes de computadores velozes e confiveis propiciam a disponibilizao de servios a um grande nmero de usurios. Para que os usurios possam acessar simultaneamente esse servio necessrio entender como program-los de forma a atingir escalabilidade. A escalabilidade de aplicaes cientficas foi bastante estudada. Mas pouco se sabe sobre escalabilidade de aplicaes comerciais.

danielc@ime.usp.br

20/30

Motivao (II)

Em particular, pouco se estudou sobre jogos de computadores, apesar de seu interesse terico e comercial. A criao de jogos interativos maciamente multiusurios um desafio. Atualmente apenas jogos do tipo RPG cuja relao temporal entre o acontecimento dos eventos e sua conseqncias menos rgida possuem verses maciamente multi-usurios (so os chamados MMORPG).

danielc@ime.usp.br

21/30

Objetivo

Utilizaremos o jogo interativo, multi-usurio, Quake disponibilizado publicamente pela Id Software sob a licena GPL para estudar a escalabilidade dessa classe de aplicaes. Nosso objetivo abstrair o workload do servidor do Quake em ambientes multi-processados, caracterizar o uso das CPUs sob tal carga e investigar possveis melhorias de aproveitamento do processamento disponvel utilizando os recursos dos sistemas operacionais Linux e K42.

danielc@ime.usp.br

22/30

Arquiteturas de Jogos Comerciais

Pouco divulgado sobre a arquitetura dos jogos comerciais. Alguns estudos indicam que a maioria utiliza-se das seguintes arquiteturas: Cliente/servidor, terminal burro; Shards e servidores distribudos; Peer-to-peer; Puramente baseado em banco-de-dados.

danielc@ime.usp.br

23/30

Arquitetura do Quake

Quake um jogo de ao interativo, multi-usurio, desenvolvido e distribudo pela Id Software. Seu lanamento, em 31 de maio de 1996, foi considerado um marco na histria dos jogos pois introduziu grandes avanos tecnolgicos em jogos 3D. A arquitetura utilizada a cliente/servidor. Os clientes conectam-se a um servidor centralizado, que responsvel por sincronizar e simular as aes dos clientes. Os clientes so responsveis por representar graficamente o estado atual do jogo e pela interao com os usurios.
24/30

danielc@ime.usp.br

Arquitetura do Quake (II)

O processamento do servidor dividido em quadros (frames) que consistem das seguintes tarefas: remoo de clientes inativos: verifica os clientes que deixaram de comunicar-se com o servidor e os remove da sesso; evoluo da simulao: evolui o modelo de simulao fsica (velocidade, acelerao, posicionamento de objetos, etc.) e o modelo do jogo (IA, efeitos de luz, som, etc.);

danielc@ime.usp.br

25/30

Arquitetura do Quake (II)

processamento de novas mensagens: o servidor processa todas as mensagens enviadas pelos clientes (tipicamente ser uma mensagem do tipo MOVE), calcula a nova posio das entidades e marca quais entidades potencialmente foram afetadas pela ao; construo e envio de respostas: o servidor envia mensagens UDP apenas para os clientes que enviaram alguma mensagem no quadro anterior. Para cada cliente, o servidor envia dados sobre os elementos alterados presentes na rea de atuao do jogador.
26/30

danielc@ime.usp.br

Resultados Preliminares

Modificaes no cdigo do Quake: Automatizao do cliente para que fosse possvel a realizao de testes com um nmero maior de usurios; Remoo do limite artificial de 32 clientes por sesso. Atualmente conseguimos manter 160 jogadores simultneos em uma sesso.

danielc@ime.usp.br

27/30

Resultados Preliminares (II)

Caracterizao do uso de CPU da verso seqencial do servidor do Quake com o auxlio do GNU Profiler (gprof) e do Linux Trace Toolkit:

17,5% do tempo foi gasto com a simulao do modelo fsico, 53,5% do tempo foi utilizado para o processamento de mensagens dos clientes, 27% para a construo das mensagens de resposta para os clientes e os outros 2% foram utilizados para outras tarefas. O processo utiliza a CPU durante aproximadamente 90% do tempo. O restante do tempo utilizado por chamadas de sistema select() e socketcall().
28/30

danielc@ime.usp.br

Plano de Trabalho

Implementao de um programa que abstraia a carga de trabalho (workload) do Quake; Investigao de paralelizao com distribuio dinmica; Conduo de experimentos no Linux e K42; Investigao de alternativas e possibilidade de melhorias nos servios fornecidos pelo sistema operacional; Redao da dissertao.

danielc@ime.usp.br

29/30

Referncias

Texto para o meu exame de qualificao do mestrado: http://www.ime.usp.br/~danielc/qualificacao.pdf E duas pginas muito boas sobre o assunto:

The C10K problem: http://www.kegel.com/c10k.html High-Performance Server Architecture: http://pl.atyp.us/content/tech/servers.html

danielc@ime.usp.br

30/30