java fix

總覽

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

是什么使它與眾不同？

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

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

但是Java不慢嗎？

Java可能比C ++慢，但是寫得好Java可能比不那么寫的C ++應(yīng)用程序快。 即僅僅因?yàn)槟承〇|西是用C ++編寫的，并不能保證它會(huì)更快。

正在測(cè)試什么？

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

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

注意：字符串和時(shí)間戳字段是最昂貴的。 有6個(gè)字符串和兩個(gè)時(shí)間戳。

在每個(gè)測(cè)試中，配置為使用SampleTime的JMH運(yùn)行了10分鐘。

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

但是較高的百分位數(shù)呢？ 這些看起來不太好。 這是因?yàn)槲艺谑褂玫挠?jì)算機(jī)有一些來自操作系統(tǒng)的噪音，例如中斷，這些中斷已被我最小化，但無法關(guān)閉。

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

接下來是什么？

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

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

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

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

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

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

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

如何使用Chronicle FIX？

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

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

結(jié)論

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

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

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

java fix

總結(jié)

以上是生活随笔為你收集整理的java fix_Java中的低延迟FIX引擎的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。