A apresentação na pythonbrasil[6] foi um sucesso, a galera gostou, questionou, foi bem bacana! Os números do cartola assustam um pouco, e as pessoas custam a acreditar no que nós conseguimos fazer com python. A palestra foi motivada em tentar ajudar a galera, que tem problemas semelhantes aos que nós passamos durante o desenvolvimento do CartolaFC.

Existe muito pouco conteúdo falando de performance em aplicações web feitas em python, e no que puder ajudar podem contar comigo! Segue a baixo a apresentação feita, ficou mais legal do que as anteriores que havia feito, o foco mudou um pouco também, tentei explicar como funciona non blocking I/O, event-based servers, e como extrair o máximo disso com ferramentas como nginx e tornado.

Nginx (pronuncia-se engine X) é um servidor HTTP de alta performance com código aberto e totalmente livre. Foi criado em 2002, pelo russo Igor Sysoev, e teve seu primeiro release liberado em 2004. O Nginx é usado em 6.55% (13.5M) dos domínios ativos no mundo, e esse número vem crescendo exponencialmente.

O Nginx é conhecido por ser muito rápido, estável, com uma grande variedade de módulos, com uma configuração muito simples além de consumir poucos recursos computacionais, como CPU e memória. Ele vem sendo utilizado em diversas aplicações, desde de um simples blog pessoal rodando em um VPS com recursos limitados, até aplicações críticas de alta disponibilidade.

Antes de tudo devemos entender como o nginx consegue ser tão performático utilizando-se de tão poucos recursos. Diferente do servidores tradicionais, nginx não utiliza threads para estabelecer conexões. Ao invés disso, ele utiliza uma arquitetura assíncrona, muito mais escalável, orientada a eventos. Isso permite que ele atenda a milhares de conexões simultâneas com pouco uso de memória e cpu. Essa arquitetura orientada a evendos é conhecida como Asynchronous non-blocking I/O e foi concebida em resposta ao The C10K problem.

O Nginx pode ser extendido com um grande variedade de módulos, que devem ser compilados junto com o código principal, antes de serem utilizados. Os mais importantes estão integrados a versão principal, e já podem ser utilizados na instalação padrão, dentre eles destaco: FastCGI, Gzip, Memcached, Proxy, Rewrite, SSI, Upstream.

Principais características do Nginx:

• Entrega de conteúdo estático, index e listagem de diretórios
• Proxy com balanceamento de carga (round-robin ou iphash) com fail-over
• Suporte a servidores FastCGI remotos com balanceamentos de carga
• Compressão com gzip
• SSI com inclusão de arquivos estáticos ou dinâmicos (através de subrequests)
• SSL
• Poderoso proxy cache reverso, com escrita em disco e configuração fácil e eficiente
• Integração direta com Memcache ou Redis

Características avançadas do Nginx:

• Servidores virtuais baseados em IP ou nome
• Suporta conexão keep-alive ou pipeline
• Configuração flexível, com timeouts e buffers
• Recarrega o arquivo de configurações, sem derrubar as conexões ativas
• Página especias de erros HTTP 400-599
• Reescrita, muito eficiente, de URLs com uso de expressões regulares
• Controle de acesso por IP ou password
• Limitação de velocidade para downloads

Arquitetura específica do Nginx:

• Um processo principal com um ou vários workers, que efetivamente manipulam as conexões
• Suporte a diferentes formas de manipulação de sockets assíncrona: kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select and poll
• Suporte a chamadas de sistema sendfile(): sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+) and sendfilev (Solaris 8 7/01+)
• Manipulação eficiente de memória, necessita de somente 2.5M de RAM para manter 10000 conexões keep-alive inativas
• Mínimo de operações de cópia de memória

Vivemos uma era onde os desafios computacionais são enormes, e esse cenário só tende a piorar. Cada dia temos mais gente acessando e se utilizando dos benefícios da internet, e isso aumenta a complexidade das aplicações, tendo em vista que a grande maioria delas terão que ser desenvolvidas para atender milhares de usuários simultaneamente. E é nesse ponto que entra o Nginx, muito mas que um simples webserver, ele possui características e features indispensáveis no desenho de soluções simples, perfomáticas e escaláveis.

Compartilhando a apresentação que fizemos na PUC-RJ, sobre a nova arquitetura do Cartola FC 2010.

Já se foi o tempo em que para se desenvolver uma aplicação web em Python se utilizava o bom e velho mod_wsgi do Apache para servi-lá. Essa arquitetura vem deixando de ser utilizada por não escalar e performar tão bem como soluções que integram application servers escritos em Python com web servers como Apache e Nginx.

No meu último projeto, precisamos implementar uma solução em python altamente performática. Quando entrei nesse projeto a estrutura que definimos como inicial era a tradicional, quando digo tradicional entenda Apache + mod_wsgi. Não tinhamos muita experiência em desenvolvimento focado em performance, e foi bem difícil encontrar cases de sucesso que pudessem nos guiar. Diria que quando decidimos implementar o novo Cartola FC, fantasy game oficial do campeonato brasileiro, em python, entramos em um túnel completamente apagado e sem luz no final, fomos na cara e na coragem, a fim de provar que performance e escalabilidade não estão ligadas a linguagem e sim a arquitetura da sua aplicação.

Após definir que faríamos em python, pelos benefícios que a linguagem trás, começamos a pensar o que seria a arquitetura ideal de uma aplicação web escrita 100% em Python. Como não tinhamos muito tempo, definimos a estrutura tradicional e seguimos em frente no desenvolvimento, sem deixar de continuar pesquisando a melhor solução.

Após algumas semanas de testes com Apache + mod_wsgi, vimos que não chegava nem perto do que queríamos. Precisávamos de uma aplicação que atendesse 3 mil requisições simultâneas, por máquina. O mod_wsgi não chegava nem perto disso, além de travar com frequência. Foi nesse momento que encontrei uma apresentação feita na pycon de 2007, Scaling Python for High-Load Web Sites, que caiu como uma luva para o nosso problema. Por que não utilizar um web server escrito em Python? Pois é, pensei a mesma coisa!

Agora vem a segunda pergunta, qual utilizar? Sem tempo a perder inciamos os testes com o CherryPy, podereso e consolidado Python web server que se mostrou robusto e performático nos testes inciais. Só que como você já sabe, nosso problema principal é performance e como atender muitas requisições simultâneas. Sobre as requisições simultâneas, descobri que não era um problema tão novo, como relatado no The C10K Problem (o problema das 10 mil conexões simultâneas), e percebi que a solução passaria necessáriamente por um web server non-blocking I/O. Aconselho a leitura do post do Akita, que faz uma imersão legal sobre non-blocking.

CherryPy apesar de ser um excelente framework, não era non-blocking e isso representaria um problema para nossas pretenções. Pequisando sobre python web server non-blocking, descobri 2 bem legais, um é o Twisted, e o outro nosso amigo Tornado. Twisted é uma engine de rede escrita em python, com suporte a diversos protocolos e com um web server non-blocking. Ele é bem completo e complexo, talvez por isso a opção pelo Tornado, que é um framework bem enxuto, com um poderoso web server non-blocking e muito simples de ser implementado.

Antes de prosseguir na escolha do melhor python web server, nos questionamos sobre o uso do tradicional Apache. Lembro que começamos com aquela estrutura tradicional, que caiu por terra com o uso de um web server escrito em python, então porquê continuar com o Apache? Ele só serviria para fazer proxy com a instância do servidor da aplicação, isso enquanto tinhamos uma única instância de CherryPy rodando por máquina, agora já temos inúmeras instâncias, e como balancear a carga entre elas? Simples, utilizando o Nginx!

O Nginx foi uma descoberta e tanto, ele é um servidor HTTP, assim como o Apache, só que possui alguns módulos bem interessantes, dentre eles o HTTP Upstream, que faz balanceamento de carga via proxy com o servidor da aplicação. Além de possuir esse módulo, o Nginx é um dos inúmeros servidores escritos para resolver o The C10K Problem, pois implementa non-blocking I/O com uso de epoll event handler. Utilizando Nginx, estaríamos tratando nossas inumeras conexões simultâneas no front end e balanceando a carga entre as instâncias dos servidores de aplicação. Isso melhorou radicalmente nosso desempenho, saimos de 200 conexões simultâneas com apache+mod_wsgi para 3 mil conexões simultâneas, sem consumo de memória e com pouco uso de CPU. Agora já podemos voltar nossas atenções para o application server, que passa a ser o nosso limitante.

Resolvemos então fazer uma implementação com o Tornado e confrontar os resultados dos testes com o CherryPy. Com o CherryPy o throughput não se mantia estável com o aumento no número de usuários simultâneos, além do alto consumos de CPU por cada instância. Já com o Tornado esses números foram animadores, o throughput se mantia linear e estável a medida que aumentávamos o número de usuários simultâneos, além do baixo consumo de CPU e consumo quase 0 de memória.

Nesse momento havíamos definido nossa arquitetura final, quase no quarto mês de um projeto que seria finalizado no seu sexto mês, nada mal! Essa arquitetura contava com 9 máquinas (Intel Quad-Core Xeon 2.5 GHz), cada máquina rodando um Nginx, balanceando a carga entre 7 servidores de aplicação construídos com Tornado, onde cada máquina pode processar 300 R/S (requisições por segundo) que dá 3K conexões simultâneas, pois uma média de 10% das conexões estabelecidas estão realizando alguma operação simultâneamente.

Para quem entrou em um túnel totalmente escuro, acredito que saímos do outro lado com um belo legado de conhecimento e descobertas que pretendo ir compartilhando com vocês. A primeira e mais importante descoberta que fizemos foi essa, performance independe de linguagem. Construa uma boa arquitetura para sua aplicação, e se ela for escrita em python, aconselho utilizar Nginx + Tornado, pois funcionam muito bem juntos. Nos meus próximos posts, irei falar bastante do Tornado e sobre como extrair o máximo dele.

Qualquer dúvida ou sugestão, deixe seu comentário aqui em baixo, terei o maior prazer em respondê-lo.