Bigtable Benchmarks
25 de maio de 2010
Visão geral executiva

Se você quiser a essência do mesmo sem os detalhes:

    * Haskell CGI é muito rápido.
    * Existem alguns problemas de desempenho importante, tanto para os pacotes fastcgi e dirigir-fastcgi.
    * Hack-fastcgi manipulador de um bom desempenho, dando esperança de que podemos ter algo semelhante para WAI.
    
    * Yesod executa muito bem em CGI, mas espero que se beneficiarão de melhorias de velocidade no wai-manipulador-fastcgi no futuro.

Introdução

Para o registro, isso não tem nada a ver com o sistema do Google banco de dados. Esta é uma referência para a saída de uma grande quantidade de HTML. Em particular, uma tabela com 1000 linhas, cada uma com 50 colunas, e cada célula com o número da coluna.

Normalmente, o valor de referência usa apenas 10 colunas, mas eu estou usando 50 porque (1) que é mais legal e (2) o snap-quadro de referência utilizados 50 colunas, e é isso que tenho essa bola rolar todo.

O ponto principal deste post é para dar dicas sobre vantagens e desvantagens de desempenho com diferentes opções em Haskell, e em particular a esclarecer sobre as melhores formas de servir aplicações Yesod.
Baseline

Vamos começar por estabelecer alguns resultados de referência. Eu vou estar executando todos os testes, exceto para servidores standalone com lighttpd em um quad-core caixa Lucid Ubuntu com 4 GB de RAM. Todos os testes estão sendo executados em localhost. Eu também estou usando a ferramenta de benchmarking Apache (ab), não é tão preciso quanto httperf, por favor, tenha em mente uma certa margem de erro quando se olha para estes números. Todos os códigos para esses parâmetros está disponível no github.

Enfim, o mais rápido resultado será, obviamente, servindo um arquivo estático. O resultado do que foi 2100 + pedidos / segundo. Representação gráfica de que esse número seria apenas estragar a escala para os outros resultados, então eu deixei-o para fora.

Para os nossos propósitos, vamos começar por comparar a saída CGI-primas. Por prima, quero dizer simplesmente imprimir na saída padrão, sem usar um pacote. Há seis diferentes resultados neste teste: C, Perl, Python são óbvias. Há, então, três versões do benchmark Haskell para bytestrings texto e cordas. Aqui está o gráfico, os números mais altos são melhores.

Os números de Perl e Python não são surpreendentes, pois eles precisam ser intrepretted para cada passagem. Também não é de surpreender que a versão string é mais lento que bytestring. O que surpreende é que o texto é mais lento do que corda! Isso exigirá mais pesquisa, uma vez que terá um grande impacto sobre Yesod, que usa o texto um pouco através da biblioteca de Hamlet.

Em seguida, vamos comparar o desempenho de alguns pacotes de diferentes CGI em Haskell.

Isso é reconfortante: o desempenho bytestring prima foi bastante próximo ao desempenho C, e os pacotes estão mantendo o ritmo. Claro, CGI não é o método ideal para a implantação de um quadro como Yesod, pois há muito a inicialização, então vamos passar para FastCGI.

Isto é onde as coisas começam a ficar depressivo. A biblioteca C está realizando incrivelmente bem, e no entanto nenhuma das bibliotecas Haskell pode manter-se. WAI é apenas um invólucro em torno direta FastCGI, então esse resultado não é surpreendente. fastcgi direta é uma implementação de Haskell pura do protocolo FastCGI, dada a sua relativa imaturidade, não é surpreendente que ele não foi otimizado ainda.

O que é chocante é lento como o pacote é fastcgi, especialmente porque é apenas envolvendo em torno de uma biblioteca C. Considerando o fato de que o FastCGI é realmente o meu método principal para a implantação de Yesod agora, eu estava muito preocupada. Eu decidi por uma chance fora ao tentar cortar-manipulador-fastcgi, e surpreendentemente, funcionou muito bem. Eu fiz uma conversão muito rápida para fazer esse trabalho conjunto com o ICT, revelando resultados muito melhores:

Há obviamente espaço para melhorias, mas pelo menos estamos na estimativa direita. Este código ainda não foi lançado em Hackage, quero limpá-lo um pouco mais em primeiro lugar, mas será certamente substituir a versão atual do manipulador fastcgi-wai.
servidores autônomos

Eu corri duas versões diferentes do padrão de referência Snap: um de seu repositório, e uma versão mais otimizada que eu escrevi. Eu faço isso para salientar uma coisa: é muito fácil com a API do Snap para escrever muito mal o código do espectáculo, já que você pode inadvertidamente criar uma grande quantidade de dados na memória.

Mesmo assim, os resultados Snap são muito menos do que o esperado. Eu estava em contato com Gregory Collins sobre isso, e ele encontrou um bug desempenho quase que imediatamente que deu os números um aumento de 40%. Moral da história: Snap tem um grande potencial, mas ainda é muito jovem.
E, finalmente, Yesod

Eu fiz um trabalho muito bom de não falar em todos os cerca de Yesod ainda. Isso porque os resultados para Yesod estão muito ligadas aos resultados acima. Estou triste em dizer que, hoje, não existe uma base sobre a qual realmente performance para executar Yesod. Isso não significa que você não pode usar Yesod, estou rodando em ambientes de produção, sem muita dificuldade. Significa apenas que eu tenho meu trabalho cortado para mim.

Além das questões do lado do servidor, Yesod em si não foi otimizado em tudo, então provavelmente há muito espaço para melhorias na biblioteca própria alma.

Devido ao processo de Yesod de inicialização, os resultados CGI são visivelmente mais lento do que CGI-primas, embora não benchmark mais lento que vimos hoje. fastcgi ainda está a sofrer a partir do pacote direto fastcgi e SimpleServer está sofrendo de seus próprios problemas (afinal, ele nunca foi destinado a dar uma carga como este).