當(dāng)前位置：首頁 > 编程语言 > java >内容正文

java

java fix_Java中的低延迟FIX引擎

發(fā)布時間：2023/12/3 java 46 豆豆

生活随笔收集整理的這篇文章主要介紹了 java fix_Java中的低延迟FIX引擎小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

java fix

總覽

Chronicle FIX是我們的Low Latency FIX引擎和Java數(shù)據(jù)庫。

是什么使它與眾不同？

是為Java中的超低GC *設(shè)計的。
支持字符串和日期時間的方式可以最大程度地減少垃圾和開銷。
可自定義為僅包含您期望的字段。
使用通常在二進制解析器和生成器中使用的優(yōu)化，例如一次讀取/寫入4或8個字節(jié)，以提高效率。
建立在低延遲持久性上，以最小化日志記錄的延遲。
針對低延遲網(wǎng)卡（例如Solarflare）進行了優(yōu)化。

*超低GC意味著平均每條消息可產(chǎn)生少于一個字節(jié)的垃圾
如果您將總垃圾率保持在每小時不足1 GB，則24 GB的Eden可能需要一整天才能填滿，并且您不會得到任何次要的GC。每小時產(chǎn)生的速度不到200 MB，您可以在沒有GC的情況下運行一周。

但是Java不慢嗎？

Java可能比C ++慢，但是寫得好Java可能比不那么寫的C ++應(yīng)用程序快。即僅僅因為某些東西是用C ++編寫的，并不能保證它會更快。

正在測試什么？

“解析器測試”乘以解析本機內(nèi)存中的214字節(jié)新順序單次FIX消息所花費的時間。從SocketChannel讀取后，將字段的所有值設(shè)置為一個對象。在此測試中，使用Strings設(shè)置文本字段，因為這是使用Java處理文本數(shù)據(jù)的更自然的方法。我們有更快的替代方案，例如支持8位字符串。

“生成器測試”乘以從包含字符串和時間戳的數(shù)據(jù)中生成214字節(jié)的New Order Single FIX消息所需的時間，并將其寫入本機內(nèi)存所需的時間。例如準(zhǔn)備寫入套接字通道。

注意：字符串和時間戳字段是最昂貴的。有6個字符串和兩個時間戳。

在每個測試中，配置為使用SampleTime的JMH運行了10分鐘。

該圖顯示了解析和生成中等大小的FIX消息的等待時間。在解析和生成中，延遲都小于一微秒，超過了99.9％的時間。

但是較高的百分位數(shù)呢？這些看起來不太好。這是因為我正在使用的計算機有一些來自操作系統(tǒng)的噪音，例如中斷，這些中斷已被我最小化，但無法關(guān)閉。

較高的延遲是由操作系統(tǒng)引起的。大約每毫秒發(fā)生一次中斷，持續(xù)約2微秒，甚至更罕見的5和7-8微秒的延遲。在更好的服務(wù)器上，我仍然希望會有中斷，但是中斷發(fā)生的頻率會降低。

接下來是什么？

下一步是將性能測試與Chronicle Journal集成在一起，以查看持久性的影響。 Journal是專門的持久性工具，類似于Chronicle Queue v4，但已針對特定用例進行了調(diào)整。在這種情況下，我們需要日記不僅要保留每條消息約150納秒的時間，而且要比Queue具有更高的一致性。盡管Queue對SSD的寫入性能非常好，但大約有1000的寫入中有1到100的寫入中有1個簽名延遲，這反映了您對磁盤子系統(tǒng)的選擇。即，它直接影響99.9％的延遲。我們可以使用Journal來緩沖此延遲，以大大減少影響。

什么是FIX數(shù)據(jù)庫？

MongoDB是為JSON消息優(yōu)化的數(shù)據(jù)庫。 Chronicle FIX是針對FIX消息優(yōu)化的數(shù)據(jù)庫。它將數(shù)據(jù)存儲在FIX中，并支持對FIX字段的查詢，例如；給我所有有關(guān)客戶訂單ID的消息，或者給我所有在特定時間發(fā)送的消息，或者給我在傳輸時間和接收消息之間最延遲的消息。

Chronicle-FIX是最快的Java代碼FIX引擎嗎？

我們已經(jīng)看到了各種FIX引擎引用的許多基準(zhǔn)統(tǒng)計數(shù)據(jù)。雖然基準(zhǔn)數(shù)字使您可以大致了解處理的數(shù)量級，但是幾乎可以肯定地，它們并不能使您確切了解代碼的運行速度。

任何人都容易宣稱自己擁有最快的FIX引擎，并帶有一些基準(zhǔn)數(shù)據(jù)來支持它，但是很難像樣地進行比較。基準(zhǔn)將始終被優(yōu)化以適合其所運行的軟件。那么，對所有發(fā)動機而言，公平的測試到底是什么呢？即使您找到了一個公平的測試，每個人都同意，您必須操縱多少代碼才能獲得基準(zhǔn)測試？用戶在編寫代碼時自然會這樣做嗎？

因此，問題是，Chronicle-FIX是最快的FIX引擎，這有點無關(guān)緊要。我們當(dāng)然知道，我們處于正確的球場。最重要的是，Chronicle-FIX已獲得咨詢許可的方式，以確保針對您的用例進行了優(yōu)化，我們將與您合作，確保您的代碼可以達到我們在基準(zhǔn)測試中發(fā)布的結(jié)果。

如何使用Chronicle FIX？

Chronicle FIX的源代碼位于github上，但僅提供給具有許可證的人員。我們的想法是，如果您需要一個非常快速的FIX引擎（以亞微秒為單位來衡量您的時間），我們可以幫助您以最佳的方式將其集成到您的軟件中。可能是您被現(xiàn)有的數(shù)據(jù)模型和代碼庫所束縛，在這種情況下，我們擁有的技術(shù)可以大大降低轉(zhuǎn)換數(shù)據(jù)的成本–實際上，我們甚至沒有中間數(shù)據(jù)模型。在一個綠色的項目中，我們可以向您展示如何最好地圍繞Chronicle-FIX構(gòu)建代碼。

請通過sales@chronicle.software與我們聯(lián)系以獲取更多信息。

結(jié)論

FIX編年史很快。盡管QuickFIX的解析和生成時間不足50微秒，但Chronicle FIX大部分時間都可以在2微秒內(nèi)完成這兩項。

我們將提供更多有關(guān)持久性如何執(zhí)行以及數(shù)據(jù)庫如何工作的文檔。

翻譯自: https://www.javacodegeeks.com/2015/09/low-latency-fix-engine-in-java.html