Comparaison des performances de Thrift, Protocol Buffers, JSON, EJB, autres?
Nous sommes à la recherche de solutions de transport et de protocole et nous étions sur le point de faire divers tests de performance. J'ai donc pensé vérifier auprès de la communauté si elle l'avait déjà fait:
Quelqu'un a-t-il effectué des tests de performances de serveur pour des services d'écho simples ainsi qu'une sérialisation/désérialisation de différentes tailles de messages comparant les tampons EJB3, Thrift et Protocol Buffers sous Linux?
Les langages seront principalement Java, C/C++, Python et PHP.
Mise à jour: Je suis toujours très intéressé par cette question. Si quelqu'un a fait d'autres tests de performance, merci de me le faire savoir. En outre, une référence très intéressante montrant JSON compressé offrant des performances similaires/meilleures que Thrift/Protocol Buffers , je lance donc JSON également sur cette question.
Dernière comparaison disponible ici sur le wiki de thrift-protobuf-compare project. Il comprend de nombreuses autres bibliothèques de sérialisation.
Je suis en train d'écrire du code dans un projet open source nommé thrift-protobuf-compare } _ comparant protobuf et thrift. Pour l'instant, il aborde quelques aspects de la sérialisation, mais j'ai l'intention d'en couvrir davantage. Les résultats (pour Thrift } et Protobuf ) sont discutés dans mon blog, je vais en ajouter plus quand j'y arriverai . Vous pouvez regarder le code pour comparer API, langage de description et code généré. Je serai heureux d'avoir des contributions pour réaliser une comparaison plus complète.
Vous pouvez être intéressé par cette question: "Les plus grandes différences de Thrift vs Protocol Buffers?"
J'ai testé les performances de PB avec plusieurs autres formats de données (xml, json, sérialisation d'objet par défaut, hessian, un propriétaire) et des bibliothèques (jaxb, infoset rapide, écrit à la main) pour la tâche de liaison de données (en lecture et en écriture), mais les formats de thrift n'étaient pas inclus. Les performances pour les formats avec plusieurs convertisseurs (comme xml) présentaient une variance très élevée, allant de très lente à très rapide. La corrélation entre les revendications des auteurs et la performance perçue était plutôt faible. Surtout pour les colis qui font les réclamations les plus folles.
Pour ce qu’il vaut, j’ai trouvé que la performance de PB était un peu exagérée (généralement pas par ses auteurs, mais par d’autres qui savent seulement qui l’a écrit). Avec les paramètres par défaut, il n'a pas battu l'alternative XML texte la plus rapide. Avec le mode optimisé (pourquoi n’est-ce pas le mode par défaut?), C’était un peu plus rapide, comparable au package JSON le plus rapide. Hessian était plutôt rapide, json textuel aussi. Le format binaire propre (sans nom ici, c’était interne à la société) était le plus lent. La sérialisation des objets Java était rapide pour les gros messages, moins pour les petits objets (c'est-à-dire que noverhead est élevé par opération) . La taille du message PB était compacte, mais compte tenu de tous les compromis que vous devez faire (les données ne sont pas auto- descriptif: si vous perdez le schéma, vous perdez des données, il y a bien sûr des index et des types de valeur, mais de ce que vous avez reconverti en reverse engineering aux noms de champs si vous le souhaitez), personnellement, je ne le choisirais que pour des cas d'utilisation spécifiques - - système étroitement lié à la taille, dans lequel l'interface/le format ne change jamais (ou très très rarement).
Mon opinion à ce propos est que (a) la mise en œuvre compte souvent plus que la spécification (du format de données), (b) de bout en bout, les différences entre les meilleurs (pour différents formats) ne sont généralement pas assez grandes pour dicter la choix ..__ C'est-à-dire qu'il vaut peut-être mieux choisir le format + API/lib/framework que vous préférez (ou le meilleur outil de support), trouver la meilleure implémentation et voir si cela fonctionne assez vite . If ( et seulement si!) pas, considérez la meilleure alternative suivante.
ps. Pas sûr de ce que serait EJB3 ici. Peut-être simplement de la sérialisation Java?
Une des choses les plus en tête de ma liste de choses à faire pour les PB est de porter le test de performance interne du tampon de protocole interne de Google. les données.
Cela fait, j'imagine que vous pouvez créer les mêmes messages dans Thrift, puis comparer les performances.
En d'autres termes, je n'ai pas encore les données pour vous - mais j'espère dans les prochaines semaines ...
Si la performance nette brute est la cible, rien ne vaut IIOP (voir RMI/IIOP) . La plus petite empreinte possible - uniquement des données binaires, pas de balisage du tout. La sérialisation/désérialisation est très rapide aussi.
Comme il s'agit de IIOP (c'est-à-dire CORBA), presque toutes les langues ont des liaisons.
Mais je présume que la performance n’est pas l’exigence seulement, non?
Pour appuyer le point de vue de Vladimir sur le programme IIOP, voici un test de performance intéressant, qui devrait fournir des informations supplémentaires par rapport aux critères de référence de Google, car il compare Thrift à CORBA. (Performance_TIDorb_vs_Thrift_morfeo.pdf // le lien n'est plus valide) Pour citer cette étude:
- Thrift est très efficace avec les petits data (types de base comme opération arguments)
- Les transports de poids ne sont pas aussi efficaces que CORBA avec moyen et données volumineuses (struct et> types complexes > 1 kilo-octets).
Une autre limite étrange, sans rapport avec les performances, est que Thrift est limité à ne renvoyer que plusieurs valeurs en tant que struct - bien que cela, tout comme les performances, puisse sûrement être amélioré.
Il est intéressant de noter que le Thrift IDL correspond étroitement au CORBA IDL de Nice. Je n'ai pas utilisé Thrift, cela semble intéressant en particulier pour les messages de petite taille, et l'un des objectifs de la conception visait une installation moins lourde, ce sont donc d'autres avantages de Thrift. Cela dit, CORBA a une mauvaise réputation, il existe de nombreuses excellentes implémentations comme omniORB par exemple, qui ont des liaisons pour Python, faciles à installer et à utiliser.
Édité: les liens Thrift et CORBA ne sont plus valides, mais j’ai trouvé un autre document utile du CERN. Ils ont évalué les remplacements de leur système CORBA et, bien qu'ils aient évalué Thrift , ils ont finalement opté pour ZeroMQ. Bien que Thrift ait réalisé les tests de performance les plus rapides, à 9 000 msg/s contre 8 000 (ZeroMQ) et 7 000+ RDA (basé sur CORBA), ils ont choisi de ne pas tester Thrift plus à cause d'autres problèmes, notamment:
C'est encore un produit immature avec une implémentation buggy
J'ai effectué une étude sur l'intégration de Spring-Boot, des mappeurs (manuel, Dozer et MapStruct), Thrift, REST, SOAP et des tampons de protocole pour mon travail.
Le côté serveur: https://github.com/vlachenal/webservices-bench
Le côté client: https://github.com/vlachenal/webservices-bench-client
Il n'est pas terminé et a été exécuté sur mes ordinateurs personnels (je dois demander des serveurs pour effectuer les tests) ... mais les résultats peuvent être consultés sur:
- Ordinateur portable: https://github.com/vlachenal/webservices-bench/blob/master/results.md
- Bureau: https://github.com/vlachenal/webservices-bench/blob/master/results-desktop.md
En conclusion:
- Thrift offre les meilleures performances et est facile à utiliser
- Le service Web RESTful avec type de contenu JSON est assez proche des performances de Thrift, est "prêt à l'emploi" et est assez élégant (de mon point de vue)
- SOAP a de très mauvaises performances mais offre le meilleur contrôle des données
- Les tampons de protocole ont de bonnes performances ... jusqu'à 3 appels simultanés ... et je ne sais pas pourquoi. C'est très difficile à utiliser: j'abandonne (pour l'instant) pour que ça marche avec MapStruct et je n'essaie pas avec Dozer.
Les projets peuvent être complétés par des demandes d'extraction (pour des corrections ou d'autres résultats).