總覽

盡管有許多可用于Java的高性能消息傳遞系統，但大多數都避免引用基準，包括持久消息傳遞和消息的序列化/反序列化。 這樣做有很多原因。 1）您并不總是需要或想要持久消息2）您希望使用自己的序列化選項。 避免使用它們的一個重要原因是，這兩種方法都會使消息傳遞速度降低多達10倍，看起來并不那么好。 大多數消息傳遞基準測試都會突出顯示傳遞原始字節而沒有持久性的性能，因為這提供了最高的數字。 有些還引用了持久消息編號，但是這些編號通常要慢得多。

如果您需要高效地對實際數據進行序列化和反序列化，并且即使您已學會了不使用這些數據，也想記錄和重播消息該怎么辦。

更高的性能序列化和耐用性

我已經寫了一個庫，試圖解決更多的問題，正如我所看到的，以便為您提供更好的整體解決方案。 它不是可用的最快消息傳遞，但是它是持久的，并且包括序列化和反序列化時間。 正如我已經指出的那樣，這可能比傳輸序列化數據的成本高10倍，因此在實際應用中，該解決方案可以更快。

示例：發送價格

在此測試InProcessChronicleTest .testPricePublishing（）中，我發送價格事件，該事件包括一個較長的時間戳，一個符號，一個出價價格/數量和要價/數量。 寫入數據的時間為0.4 μS（0.0004毫秒），通過TCP連接接收數據的時間為1.8 μS。

注意：此連接在兩端都是持久的，因此您可以查看哪些數據已排隊發送和已接收。 如果連接丟失，即使服務器不可用（例如，重新啟動客戶端），它也可以從原來的位置繼續播放，或者可以選擇播放客戶端已經收到的任何消息。

為了發送和接收500萬條消息，我使用了-Xmx32m -verbosegc標志，該標志表明只需要很少的堆，并且在此測試過程中沒有發生任何GC。 這意味著該庫對您的其余應用程序影響很小。

與外部化對象進行比較。

為了說明這一點，我將其與在InProcessChronicleTest中序列化和反序列化包含相同數據的對象所需的時間進行了比較。 testSerializationPerformance（）。 PriceUpdate對象是可外部化的，并且該基準測試 “比較JVM平臺上序列化庫的各個方面”表明，可外部化對象可以是可用的最快序列化之一。 在同一臺計算機上花費的時間是2.7 μS進行序列化和7.5 μS進行反序列化。 注意：這不包括消息傳遞或持久性，僅用于序列化和反序列化。

序列化 運輸 寫作時間 時間閱讀

Java紀事	TCP和持久性	0.4微秒	1.8微秒
可外部化	沒有	2.7微秒	7.5微秒
可序列化	沒有	3.8微秒	13.2微秒

結論

在對消息傳遞進行基準測試時，您應該包括發送和接收真實消息所花費的時間，而不僅是byte []，還包括持久性（如果需要）。

參考：我們的JCG合作伙伴 Peter Lawrey在Vanilla Java博客上的高性能持久消息 。

翻譯自: https://www.javacodegeeks.com/2013/02/high-performance-durable-messaging.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的高性能持久消息的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。