it-swarm.com.de

Leistungsvergleich von Thrift, Protokollpuffer, JSON, EJB, andere?

Wir beschäftigen uns mit Transport-/Protokolllösungen und waren kurz davor, verschiedene Leistungstests durchzuführen. Ich dachte, ich würde mich an die Community wenden, wenn sie das schon getan haben:

Hat jemand Serverleistungstests für einfache Echodienste sowie für die Serialisierung/Deserialisierung für verschiedene Nachrichtengrößen durchgeführt und EJB3-, Thrift- und Protokollpuffer unter Linux verglichen?

Sprachen werden hauptsächlich Java, C/C++, Python und PHP sein.

Update: Ich bin immer noch sehr daran interessiert. Falls jemand weitere Benchmarks durchgeführt hat, lass es mich wissen. Sehr interessanter Benchmark zeigt komprimiertes JSON, das ähnliche/bessere Ergebnisse erzielt als Thrift/Protocol Buffers , deshalb setze ich JSON ebenfalls in diese Frage.

65
Parand

Der letzte Vergleich ist hier im thrift-protobuf-compare Projekt-Wiki verfügbar. Es enthält viele andere Serialisierungsbibliotheken.

53
Eishay Smith

Ich schreibe gerade etwas Code in einem Open Source-Projekt mit dem Namen thrift-protobuf-compare und vergleicht Protobuf mit Thrift. Momentan werden nur wenige Aspekte der Serialisierung behandelt, aber ich möchte noch mehr abdecken. Die Ergebnisse (für Thrift und Protobuf ) werden in meinem Blog besprochen, ich werde weitere hinzufügen, wenn ich dazu komme ... Sie können den Code zum Vergleichen der API, der Beschreibungssprache betrachten und generierter Code. Ich freue mich über Beiträge, die einen abgerundeten Vergleich ermöglichen. 

15
eishay

Sie könnten an dieser Frage interessiert sein: "Größte Unterschiede zwischen Thrift- und Protokollpuffern?"

8
user38123

Ich habe die Leistung von PB mit einer Anzahl anderer Datenformate (xml, json, Standardobjekt-Serialisierung, hessian, ein proprietäres Format) und Bibliotheken (jaxb, Fast-Infoset, handgeschrieben) für die Datenbindungsaufgabe (sowohl Lesen als auch Schreiben) getestet. aber das Format der Sparsamkeit war nicht enthalten. Die Leistung für Formate mit mehreren Konvertern (z. B. XML) zeigte eine sehr hohe Varianz, von sehr langsam bis ziemlich schnell. Die Korrelation zwischen den Behauptungen der Autoren und der wahrgenommenen Leistung war eher schwach. Dies gilt insbesondere für Pakete, die wildeste Ansprüche stellen.

Für das, was es wert ist, habe ich festgestellt, dass die Leistung von PB etwas übertrieben ist (normalerweise nicht von den Autoren, sondern von anderen, die nur wissen, wer sie geschrieben hat). Mit den Standardeinstellungen wurde die schnellste Alternative zu Text-XML-Dateien nicht übertroffen. Mit dem optimierten Modus (warum ist dies nicht der Standard?), War es etwas schneller, vergleichbar mit dem schnellsten JSON-Paket. Hessian war ziemlich schnell, auch Text-Json. Das proprietäre binäre Format (hier kein Name, es war firmenintern) war das langsamste. Die Java-Objektserialisierung war für größere Nachrichten schnell, für kleine Objekte weniger (dh für hohe noverhead-Vorgänge pro Operation) ..__ Mit PB war die Nachrichtengröße zwar kompakt, aber bei allen Kompromissen müssen Sie dies tun (Daten sind nicht selbstständig). beschreibend: Wenn Sie das Schema verlieren, verlieren Sie Daten, es gibt natürlich Indizes und Werttypen, aber von dem, was Sie über Reverse-Engineering zu Feldnamen haben (wenn Sie möchten), würde ich es nur für bestimmte Anwendungsfälle auswählen. - größenabhängiges, eng gekoppeltes System, bei dem sich Schnittstelle/Format niemals (oder sehr selten) ändert.

Meiner Meinung nach ist (a) die Implementierung oftmals wichtiger als die Spezifikation (des Datenformats), (b) Ende-zu-Ende, Unterschiede zwischen Best-of-Breed (für verschiedene Formate) sind normalerweise nicht groß genug, um das zu bestimmen choice . Das heißt, Sie können besser Format + API/lib/Framework wählen, das Sie am besten verwenden (oder beste Werkzeugunterstützung haben), die beste Implementierung finden und prüfen, ob dies schnell genug funktioniert .__ (Wenn ( und nur wenn!) nicht, die nächstbeste Alternative in Betracht ziehen.

ps. Nicht sicher, was EJB3 hier wäre. Vielleicht einfach nur Java-Serialisierung?

7
StaxMan

Ganz oben auf meiner "To-Do" -Liste für PBs ist das Portieren des internen Benchmark-Performance-Benchmarks für Googles. Hierbei handelt es sich meistens um vertrauliche Nachrichtenformate, die in völlig harmlose Formate umgewandelt werden, und dann dasselbe die Daten.

Wenn das erledigt ist, könnte ich mir vorstellen, dass Sie dieselben Nachrichten in Thrift erstellen und dann die Leistung vergleichen können.

Mit anderen Worten, ich habe noch keine Daten für Sie - aber hoffentlich in den nächsten Wochen ...

4
Jon Skeet

Wenn die reine Netto-Performance das Ziel ist, ist nichts besser als IIOP (siehe RMI/IIOP) . Die Serialisierung/Deserialisierung ist ebenfalls sehr schnell.

Da es sich um IIOP (das ist CORBA) handelt, haben fast alle Sprachen Bindungen.

Aber ich nehme an, die Leistung ist nicht die nur -Anforderung, richtig?

4

Um den Punkt von Vladimir über IIOP zu unterstreichen, hier ein interessanter Leistungstest, der einige zusätzliche Informationen zu den Google-Benchmarks geben sollte, da Thrift und CORBA miteinander verglichen werden. (Performance_TIDorb_vs_Thrift_morfeo.pdf // link ist nicht mehr gültig) Zitat aus der Studie:

  • Thrift ist sehr effizient mit kleinen Daten (Grundtypen als Operation Argumente)
  • Thrifttransporte sind mit CORBA und .__ nicht so effizient wie CORBA. große Daten (Struktur und> komplexe Typen> 1 Kilobyte).

Eine andere merkwürdige Einschränkung, die sich nicht auf die Leistung bezieht, besteht darin, dass Thrift darauf beschränkt ist, nur mehrere Werte als Struktur zurückzugeben - obwohl dies ebenso wie die Leistung sicherlich verbessert werden kann. 

Es ist interessant, dass die Thrift-IDL eng mit der CORBA-IDL (Nice) übereinstimmt. Ich habe Thrift nicht verwendet, es sieht besonders für kleinere Nachrichten interessant aus, und eines der Entwurfsziele war eine weniger umständliche Installation, daher sind dies weitere Vorteile von Thrift. Das heißt, CORBA hat einen schlechten Ruf. Es gibt viele hervorragende Implementierungen wie omniORB , die Bindungen für Python haben, die einfach zu installieren und zu verwenden sind.

Bearbeitet: Die Thrift- und CORBA-Verknüpfung ist nicht mehr gültig, aber ich habe ein weiteres nützliches Dokument vom CERN gefunden. Sie bewerteten die Ersetzung ihres CORBA-Systems, und während sie evaluierte Thrift waren, gingen sie schließlich zu ZeroMQ. Während Thrift bei ihren Leistungstests mit 9000 msg/s im Vergleich zu 8000 (ZeroMQ) und 7000+ RDA (CORBA-basiert) die schnellste Leistung erbrachte, entschieden sie sich, Thrift aus anderen Gründen nicht weiter zu testen.

Es ist immer noch ein unreifes Produkt mit einer fehlerhaften Implementierung

3
michaelok

Ich habe eine Studie für Spring-Boot, Mapper (Manual, Dozer und MapStruct), Thrift, REST, SOAP und Protocol Buffers für meinen Job gemacht.

Die Serverseite: https://github.com/vlachenal/webservices-bench

Die Client-Seite: https://github.com/vlachenal/webservices-bench-client

Es ist noch nicht fertig und wurde auf meinen PCs ausgeführt (ich muss Server um die Tests abschließen) ... aber die Ergebnisse können abgerufen werden:

Als Schlussfolgerung :

  • Thrift bietet die beste Leistung und ist einfach zu bedienen
  • RESTful Webservice mit JSON-Inhaltstyp entspricht ziemlich der Thrift-Leistung, ist "Browser ready to use" und ist aus meiner Sicht recht elegant
  • SOAP weist eine sehr schlechte Leistung auf, bietet jedoch die beste Datenkontrolle
  • Protocol Buffers hat eine gute Leistung ... bis zu 3 gleichzeitige Anrufe ... und ich weiß nicht warum. Es ist sehr schwierig zu benutzen: Ich gebe (vorerst) auf, damit MapStruct funktioniert und ich versuche es nicht mit Dozer.

Projekte können durch Pull-Anfragen abgeschlossen werden (entweder für Fixes oder andere Ergebnisse).

0
user4047208