Quelqu'un a-t-il des informations sur les caractéristiques de performance des tampons de protocole par rapport à BSON (JSON binaire) ou par rapport à JSON en général ?
Ces protocoles semblent être de bons protocoles binaires à utiliser sur HTTP. Je me demande simplement lequel serait le meilleur à long terme pour un environnement C#.
Voici quelques informations que j'ai lues sur le sujet BSON et Tampons de protocole .
Ce poste compare les vitesses et les tailles de sérialisation dans .NET, notamment JSON, BSON et XML.
http://james.newtonking.com/archive/2010/01/01/net-serialization-performance-comparison.aspx
Économie d'argent est également une autre alternative de type Protocol Buffers.
Il existe de bons repères de la communauté Java sur la sérialisation/désérialisation et la taille des fils de ces technologies : https://github.com/eishay/jvm-serializers/wiki
En général, JSON a une taille de fil légèrement supérieure et un DeSer légèrement moins bon, mais il gagne en omniprésence et en capacité à être interprété facilement sans l'IDL source. Le dernier point est quelque chose que Apache Avro tente de résoudre, et il bat les deux en termes de performance.
Microsoft a publié un paquet C# NuGet Microsoft.Hadoop.Avro .
Une petite taille de message ne se traduit pas automatiquement par une perfamnce rapide, voir cet article. soa.sys-con.com/node/250512
Bon lien ; la seule chose dont je ne suis pas sûr est le commentaire sur Avro -- alors qu'il pourrait fonctionner plus efficacement pour ses cas d'utilisation principaux (des tonnes d'entrées de données similaires), il ne semble pas être très rapide dans ce benchmark (qui teste le traitement d'une seule requête).
Voici quelques repères récents montrant la performance des sérialiseurs .NET les plus populaires.
Le site benchmarks Burning Monks montrent les performances de la sérialisation d'un simple POCO alors que le système complet Points de référence de Northwind montrent les résultats combinés de la sérialisation d'une ligne dans chaque table de l'ensemble de données Northwind de Microsoft.
Fondamentalement, les tampons de protocole ( protobuf-net ) est d'environ 7x plus rapide que le Serializer de la bibliothèque de classes de base le plus rapide de .NET (XML DataContractSerializer). Il est également plus petit que ses concurrents, car il est également 2.2x plus petit que le format de sérialisation le plus compact de Microsofts (JsonDataContractSerializer).
Les sérialiseurs de texte de ServiceStack sont les plus proches de la performance du protobuf-net binaire où ses Sérialiseur Json est seulement 2.58x plus lent que protobuf-net.
Les tampons du protocole sont conçus pour le fil :
JSON est juste du texte et il doit être analysé . indice : encoder un "milliard" d'int dans ce code prendrait pas mal de caractères : Milliard = 12 caractères (échelle longue), en binaire cela tient dans un uint32_t. Et si on essayait d'encoder un double ? ce serait bien plus grave.
Cependant, elle présente l'inconvénient plutôt malheureux de ne pas gérer l'héritage et, bien que la composition soit une alternative valable, je préfère ne pas être forcé par mon objet de transfert de données à utiliser la composition plutôt que l'héritage.
Je crois que les extensions peuvent être utilisées d'une manière très similaire à l'héritage... developers.google.com/protocol-buffers/docs/reference/
Oui, les extensions sont un très bon point. Je l'utilise en pratique tous les jours au travail.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Certains soutiennent (je pense que cela inclut un ancien auteur de protobuf) que c'est une meilleure idée d'utiliser un format plus grand mais moins cher à sérialiser et ensuite de compresser la sortie avec un compresseur standard rapide.
0 votes
devblog.corditestudios.com/blog/2012/10/29/
0 votes
Je ne pense pas qu'il faille rouvrir le débat tant qu'une certaine méthode de comparaison n'a pas été proposée dans la question elle-même (sinon, il s'agit d'un débat plutôt subjectif et trop large).
0 votes
Peut-être davantage en termes de forces et de faiblesses de chaque format, et la réponse pourrait inclure un arbre de décision.