我們正在調查傳輸/協議的解決方案和即將做各種性能的測試，所以我想我會與社會各界檢查，如果他們已經做到了這一點：Thrift，協議緩衝區，JSON，EJB和其他的性能比較？
有簡單的人做的服務器性能測試echo服務以及在Linux上比較EJB3，Thrift和Protocol Buffers的各種消息大小的序列化/反序列化？
主要語言爲Java，C/C++，Python和PHP。
更新：我仍然對此很感興趣，如果任何人做過任何進一步的基準，請讓我知道。此外，非常有趣的基準顯示compressed JSON performing similar/better than Thrift/Protocol Buffers，所以我也把JSON扔進這個問題。
可以在這裏找到在thrift-protobuf-compare項目wiki最新的比較。它包含許多其他序列化庫。
一個靠近我的PBS的「待辦事項」列表的頂部的事情之一就是港口谷歌的內部協議緩衝性能基準測試 - 它主要採取的情況下，機密信息格式並將它們變成完全無用的格式，然後對數據進行相同處理。
當一個已經做了，我想像你可以建立儲蓄同一消息，然後比較性能。
換句話說，我沒有爲你的數據 - 但是希望在接下來的幾個星期...
Thrift-protobuf比較項目（http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking）將是一個很好的家園，如果你做了什麼？能夠看到不同的用例會很棒 - 當前的用戶處理非常小的消息，這只是一個區域。 – StaxMan 2009-04-24 18:30:37
我現在有一個基準測試框架，但它*主要*旨在對協議緩衝區和不同消息的不同實現進行基準測試。請參閱http://code.google.com/p/protobuf-csharp-port/wiki/ProtoBench – 2009-04-24 19:01:31
如果原始淨值表現是目標，那麼沒有什麼比IIOP（見RMI/IIOP）。 最小的可能空間 - 只有二進制數據，根本沒有標記。序列化/反序列化也非常快。
因爲它是IIOP（即CORBA），幾乎所有的語言都綁定。
。不過我想表現的不只是要求，對不對？
性能絕對不是唯一的要求。我們可以很容易地處理或可以評估其他要求;性能是我一直在尋求反饋的。 – Parand 2008-11-17 23:12:02
「只有二進制數據」並不意味着它是最小的可能的佔地面積。例如，您可以將Int32傳輸爲「僅4字節」或使用可減少小值傳輸大小的編碼，但需要將更多數據用於大值。 – 2008-11-18 09:11:52
我在寫在open source project named thrift-protobuf-compare一些代碼的protobuf和節儉之間進行比較的過程。目前它涵蓋了很少的序列化方面，但我打算覆蓋更多。結果（對於Thrift和Protobuf）在我的博客中進行了討論，我會在添加更多內容時加以說明。 您可以查看代碼以比較API，描述語言和生成的代碼。我很樂意爲實現更全面的比較做出貢獻。
我測試了其他數據格式（xml，json，默認對象序列化，hessian，一個專有版本）和庫（jaxb，快速信息集，手寫）和寫作），但節儉的格式不包括在內。具有多個轉換器（如xml）的格式的性能差異非常大，從非常慢到非常快。作者聲稱與感知表現之間的相關性很弱。特別是對於那些做出最瘋狂索賠的軟件包。
對於什麼是值得，我發現PB性能是有點過分誇大（通常不是由它的作者，但其他人誰只知道是誰寫的）。使用默認設置，它沒有擊敗最快的文本XML替代。有了優化模式（爲什麼這不是默認？），它速度更快，與最快的JSON軟件包相媲美。 Hessian的速度相當快，文本JSON也是。正確的二進制格式（這裏沒有名稱，它是公司內部的）是最慢的。 Java對象序列化對於較大的消息來說是快速的，對於小對象來說則更少（即對每個操作的高度固定的noverhead）。 用PB郵件大小緻密，但由於你所要做的所有的權衡（數據不自我描述：如果你失去了架構，你失去的數據;當然有指標，和值類型，但是從你如果你願意的話，可以反向工程回到字段名稱），但我個人只會選擇它用於特定用例 - 尺寸敏感，緊密耦合的系統，其中界面/格式從不（或非常非常罕見）更改。 （a）實現通常比規範（數據格式）更重要，（b）端到端，同類最佳（針對不同格式）之間的差異通常並不大足以決定選擇。 也就是說，你可能會更好選擇格式+的API/lib中/框架您喜歡使用最多（或有最好的工具支持），找到最好的實現，並看看是否能工程速度不夠快。 如果（並且只有！）不，請考慮下一個最佳選擇。
PS。不確定這裏的EJB3是什麼。也許只是簡單的Java序列化？
要備份弗拉基米爾點約IIOP，這裏是一個有趣的性能測試，應該給在谷歌基準些有用的信息，因爲它比較節儉和CORBA。 （Performance_TIDorb_vs_Thrift_morfeo.pdf //鏈接不再有效） 從研究中引用：
- 節約是非常有效的小 數據（基本類型，操作 參數）
- 勤儉島運輸並非如此有效，因爲與介質CORBA和 大數據（結構和>複雜 類型> 1千字節）。
另一個奇數限制，而不是具有性能做，是節儉被限制爲僅返回幾個值作爲一個結構 - 儘管這，像性能，能夠可靠地或許改善。
有意思的是，節儉IDL匹配的CORBA IDL，美觀大方。我沒有使用過Thrift，它看起來很有趣，特別是對於較小的消息，並且其中一個設計目標是安裝較少麻煩，所以這些是Thrift的其他優點。也就是說，CORBA有一個不好的說唱，有很多優秀的實現，例如omniORB，它具有Python的綁定，易於安裝和使用。
編輯：Thrift和CORBA鏈接不再有效，但我確實從CERN找到了另一篇有用的論文。他們評估了他們的CORBA系統的替代品，並且，他們最終與ZeroMQ一起使用了evaluated Thrift。雖然節儉執行他們的性能測試中最快的，在9000味精/秒與8000（ZeroMQ）和7000+ RDA（基於CORBA的），他們沒有選擇進一步檢驗，因爲特別是其他問題節儉：
它仍然是一個不成熟的產品有越野車實施
我已經做了春天開機，映射器（手動，推土機和MapStruct），節儉，REST，SOAP和協議緩衝區集成我的工作進行了研究。
服務器端：https://github.com/vlachenal/webservices-bench
客戶端：https://github.com/vlachenal/webservices-bench-client
還沒有完成，並已在我的個人電腦（我要問的服務器來完成測試）運行......但結果可以諮詢：
至於結論：
項目可以通過pull請求完成（對於修復或其他結果）。
ASN.1可以成爲研究的一部分嗎？ – Vincent 2010-08-24 14:28:41
謝謝。我很想看看[Fast Infoset]（http://en.wikipedia.org/wiki/Fast_Infoset）（ITU-T X.891建議書| ISO/IEC 24824-1）和[EXI]（http：///en.wikipedia.org/wiki/Efficient_XML_Interchange）（W3C）。 – nealmcb 2012-02-29 06:45:22
從https://code.google.com/p/thrift-protobuf-compare/wiki/BeyondNumbers看來，JSON基準測試只是手動將縮寫字符串寫入輸出。 – h22 2015-02-10 10:54:47