Melhorando a performance do ZEO

Enquanto o prêmio da Arena não chega e o Felipe/Otávio não mandam sinal de fumaça, digo, a avaliação das duas fases do Insanifying, que gerou a classificação final das quatro equipes, vou comentar a respeito de algumas mudanças quase imperceptíveis que vêm ocorrendo no ZEO nos últimos tempos. Caso a sua instalação atual do ZEO venha apresentando problemas de lentidão e/ou travamentos parciais, você vai descobrir os motivos... :-)

O servidor de aplicações Zope utiliza o ZODB (Zope Object Database) como mecanismo de persistência de objetos Python. Normalmente a área de armazenamento do ZODB pode ser usada apenas por um único processo (com uma ou mais threads, sendo quatro o número padrão). O ZEO (Zope Enterprise Objects) é a solução da Zope Corp para o compartilhamento de uma área de armazenamento única entre diversos clientes.

Quando o ZEO é utilizado, a área de armazenamento é acessada pelo processo do servidor ZEO. Então, diversos clientes podem se conectar a este servidor, de forma a compartilhar a mesma área de armazenamento. O ZEO sempre fornece uma visão consistente dos dados para todos os clientes que estiverem conectados. A comunicação entre o servidor e os clientes é feita usando uma versão personalizada do protocolo RPC, em cima do TCP.

No final do mês de março, após o lançamento das versões 2.9.7 e 2.10.3 do Zope, um bug que gerava um tempo de espera excessivamente longo após determinadas operações foi descoberto e resolvido, quase ao mesmo tempo, individualmente por duas pessoas, em locais diferentes.

A primeira solução foi apresentada pelo Jürgen Kartnaller, em 27/03/2007. Ela consistia na implementação de uma função sleep com suporte a nonosegundos, para contonar o problema da granularidade do sleep de algumas plataformas.

A segunda solução foi apresentada pouco mais de 24 horas depois, pelo já lendário Jim Fulton, também conhecido como "O" criador do Zope (qualquer semelhança com o Homer Simpson é mera coincidência!). Ele descobriu que o timeout para uma condição de chamada em espera era desnecessário, além de eliminar uma parte não assíncrona do código.

Posteriormente, parte da solução do Jim foi aplicada nos braches correspondentes às versões do ZODB que acompanham o Zope das séries 2.9.x e 2.10.x. Cabe salientar que a implementação do Jürgen se tornou desnecessária, uma vez que o timeout foi removido e com ele a chamada ao sleep.

É importante também dizer que, até o presente momento, estes aperfeiçoamentos ainda não fazem parte de nenhuma versão oficialmente lançada. Entretanto elas farão parte das versões 2.9.8 e 2.10.4, assim que elas saírem do forno.

Na tarde desta sexta-feira o Jim informou sobre mais uma possível otimização, desta vez na configuração dos parâmetros que definem os tempos mínimos (min-disconnect-poll) e máximos (max-disconnect-poll) de espera entre as tentativas de reconexão, quando os clientes se desconectam do servidor ZEO. Os valores padrão são 5 e 300 segundos e a intenção é passar a usar 1 e 6 segundos de agora em diante.

Devo confessar que nunca havia visto estes dois parâmetros antes, mas graças à mensagem do Jim e a um grep no fonte do Zope eu cheguei até o arquivo doc/ZEO/howto.txt, que explica estas e muitas outras opcões.

Os testes no ZEO passaram a rodar 25% mais rápido e o impacto em um sistema em produção pode ser ainda maior. Caso as dicas tenham sido úteis, não deixe de postar um comentário relatando a diferença de performance obtida na sua instalação.