comparação de desempenho de Thrift, Protocol Buffers, JSON, EJB, outros?

StackOverflow https://stackoverflow.com/questions/296650

Pergunta

Nós estamos olhando para transporte soluções / protocolo e estavam prestes a fazer vários testes de desempenho, então eu pensei que eu iria verificar com a comunidade se eles já fizeram isso:

Alguém já fez testes de desempenho do servidor para serviços de eco simples, bem como serialização / desserialização para várias mensagens tamanhos comparando EJB3, Thrift, e Protocol Buffers no Linux?

Primeiramente línguas será Java, C / C ++, Python e PHP.

Update: Eu ainda estou muito interessado nisso, se alguém fez quaisquer outras referências por favor me avise. Além disso, referência muito interessante mostrando comprimido JSON realizando / semelhante melhor do que Thrift / Protocol Buffers , então eu 'm jogando JSON para esta pergunta também.

Foi útil?

Solução

Últimas comparação disponíveis aqui no wiki do projeto thrift-protobuf comparar. Ele inclui muitas outras bibliotecas de serialização.

Outras dicas

Eu estou no processo de escrever algum código em uma poupança projeto de código aberto chamado -protobuf- comparar comparação entre Protobuf e economia. Por enquanto ele cobre alguns aspectos de serialização, mas tenho a intenção de cobrir mais. Os resultados (por Thrift e Protobuf ) são discutidos no meu blog, vou acrescentar mais quando eu vou chegar a ele. Você pode olhar o código para comparar API, linguagem de descrição e código gerado. Eu vou ser feliz de ter contribuições para conseguir uma comparação mais arredondado.

Você pode estar interessado nesta questão: "maiores diferenças de Thrift vs Protocol buffers? "

Eu fiz o desempenho no teste de PB com o número de outros formatos de dados (XML, JSON, serialização de objeto padrão, hessian, um um proprietário) e bibliotecas (jaxb, infoset rápido, escrita à mão) tarefa para a ligação de dados (leitura e escrevendo), mas o formato de poupança (s) não foi incluído. Desempenho de formatos com vários conversores (como xml) teve muito alta variância, de muito lento para pretty-maldito-rápido. Correlação entre reivindicações de autores e desempenho percebido foi bastante fraco. Especialmente para os pacotes que fizeram reivindicações mais selvagens.

Por que vale a pena, eu achei desempenho PB a ser pouco mais sensacionalistas (geralmente não por seus autores, mas outros que só sabem que o escreveu). Com as configurações padrão que não batia alternativa xml mais rápido textual. Com o modo otimizado (porque é que este não padrão?), Era pouco mais rápido, comparável com o pacote JSON mais rápido. Hessian foi bastante rápido, textual json também. formato binário Properietary (sem nome aqui, foi interno da empresa) foi o mais lento. Java objecto serialização foi rápido para mensagens maior, menos para pequenos objectos (isto é, elevado fixo noverhead por operação). Com PB tamanho da mensagem foi compacto, mas dado todos os trade-offs que você tem que fazer (dados não é auto-descritivo: se você perder o esquema, você perder dados, existem índices é claro, e tipos de valor, mas pelo que você tem volta a campo nomes engenharia inversa, se você quiser), eu pessoalmente só iria escolhê-lo para casos de uso específicos -, o sistema de perto juntamente sensível ao tamanho onde Interface / formato nunca mais (ou muito raramente) muda

.

A minha opinião neste é que (a) implementação, muitas vezes é mais importante que a especificação (de formato de dados), (b) end-to-end, as diferenças entre best-of-breed (para diferentes formatos) geralmente não são grandes o suficiente para ditar a escolha. Ou seja, você pode ser melhor escolher formato + API / lib / framework você gosta de usar mais (ou tem melhor suporte de ferramentas), encontrar o melhor implementação e ver se isso funciona rápido o suficiente. Se (e somente se!) Não, considere melhor alternativa.

ps. Não sei o que EJB3 aqui seria. Talvez simplesmente de serialização Java?

Uma das coisas perto do topo da minha lista "para-fazer" para a PBS é a porta de referência de desempenho buffer de protocolo interno do Google - é principalmente um caso de tomar formatos de mensagens confidenciais e transformá-los em mais completamente sem graça, e em seguida, fazendo o mesmo para os dados.

Quando isso foi feito, eu imagino que você poderia construir as mesmas mensagens em Thrift e depois comparar o desempenho.

Em outras palavras, eu não tenho os dados para que você ainda - mas espero que no próximo par de semanas ...

Se o desempenho líquido cru é o alvo, então nada bate IIOP (ver RMI / IIOP). Menor pegada possível - apenas dados binários, sem marcação em tudo. Serialização / desserialização é muito rápido também.

Desde a sua IIOP (isto é CORBA), quase todas as línguas têm ligações.

Mas eu presumo que o desempenho não é o única exigência, certo?

Para fazer backup de ponto de Vladimir sobre IIOP, aqui está um teste de desempenho interessante, que deve dar algumas informações adicionais sobre os valores de referência do Google, uma vez que compara Thrift e CORBA. (Performance_TIDorb_vs_Thrift_morfeo.pdf // link não válido) Para citar o estudo:

  • Thrift é muito eficiente com pequena dados (tipos básicos como a operação argumentos)
  • Thrifts transportes não são tão eficientes como CORBA com médio e grandes dados (struct e> complexa tipos> 1 kilobytes).

Outra limitação estranha, não tendo a ver com desempenho, é que Thrift é limitado a só retornando vários valores como uma struct - embora este, como performance, certamente pode ser melhorado, talvez.

É interessante que o Thrift IDL aproxima do CORBA IDL, agradável. Eu não usei Thrift, parece interessante, especialmente para mensagens menores, e um dos objetivos do projeto foi para um menos pesado instalar, assim que estas são outras vantagens da poupança. Dito isto, CORBA tem uma má reputação, existem muitas implementações excelentes lá fora, como omniORB por exemplo, que tem ligações para Python, que são fáceis de instalar e usar.

Editado: O Thrift e ligação CORBA não é mais válido, mas eu encontrei um outro papel útil do CERN. Eles avaliaram substitutos para o seu sistema CORBA, e, enquanto eles avaliadas Thrift , que acabou indo com ZeroMQ. Enquanto Thrift realizada o mais rápido em seus testes de desempenho, em 9000 msg / seg vs. 8000 (ZeroMQ) e 7000+ RDA (CORBA-based), eles optaram por não Thrift teste ainda mais por causa de outras questões, nomeadamente:

É ainda um produto imaturo com uma implementação de buggy

Eu tenho feito um estudo para a primavera-boot, mapeadores (manual, bulldozer e MapStruct), parcimônia, descanso, sabão e integração Protocol Buffers para o meu trabalho.

O lado do servidor: https://github.com/vlachenal/webservices-bench

O lado do cliente: https://github.com/vlachenal/webservices-bench-client

Não é acabado e foi executado em meus computadores pessoais (eu tenho que perguntar para servidores para completar os testes) ... mas os resultados podem ser consultados em:

Como conclusão:

  • Thrift oferece o melhor desempenho e é fácil de usar
  • webservice REST com JSON tipo de conteúdo é muito parecido com o desempenho Thrift, é "navegador pronto para usar" e é bastante elegante (do meu ponto de vista)
  • SABÃO tem desempenho muito pobre, mas oferece o melhor controle de dados
  • Protocol Buffers tem o bom desempenho ... até 3 chamadas simultâneas ... e eu não sei porquê. É muito difícil de usar:. Eu desisto (por agora) para fazer para ele trabalhar com MapStruct e eu não tentar com Dozer

Os projetos podem ser concluídos através de solicitações de pull (tanto para correções ou outros resultados).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top