總覽

Chronicle FIX是我們的Low Latency FIX引擎和Java數據庫。

是什么使它與眾不同？

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

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

但是Java不慢嗎？

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

正在測試什么？

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

“生成器測試”乘以從包含字符串和時間戳的數據中生成214字節的New Order Single FIX消息所需的時間，并將其寫入本機內存需要多長時間。 例如準備寫入套接字通道。

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

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

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

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

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

下一步是什么？

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

什么是FIX數據庫？

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

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

我們已經看到了各種FIX引擎引用的許多基準統計數據。 盡管基準數字可以使您大致了解處理的數量級，但是幾乎可以肯定它們并不能使您確切了解代碼的運行速度。

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

因此，問題是，Chronicle-FIX最快的FIX引擎是否有些無關緊要。 我們當然知道，我們處于正確的球場。 最重要的是，Chronicle-FIX已獲得咨詢許可的方式，以確保針對您的用例進行了優化，我們將與您合作，確保您的代碼可以達到我們在基準測試中發布的結果。

如何使用Chronicle FIX？

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

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

結論

FIX編年史很快。 盡管QuickFIX的解析和生成時間不足50微秒，但Chronicle FIX在大多數情況下都可以在2微秒內完成這兩項。

我們將提供更多有關持久性如何執行以及數據庫如何工作的文檔。

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

總結

以上是生活随笔為你收集整理的Java中的低延迟FIX引擎的全部內容，希望文章能夠幫你解決所遇到的問題。

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