對於 FIX 引擎，什麼被認為是好的/有競爭力的吞吐量？
我正在編寫自己的 FIX 引擎，並且正在執行一些基準測試。我不確定我的結果是好是壞。在該領域有經驗的人可以為我提供一些基準吞吐量數字嗎？我的客戶端每秒應該能夠處理多少條 FIX 消息？
我們相信 FIX 解析器（編碼器/解碼器）是 FIX 引擎中最容易優化的部分。瓶頸通常是網路 I/O，因為在從網路接收/向網路發送字節之前，您無法進行任何編碼/解碼。
以下是我們使用 Intel Xeon 2.0GHz 機器測量的CoralFIX數字：
在編碼方面（從
FixMessage到ByteBuffer），我們可以在平均每條消息 1.408 微秒內對 500 萬條消息進行編碼而不會產生任何垃圾。在解碼（從
ByteBuffer到FixMessage）方面，我們可以在平均每條消息 1.997 微秒內解碼 500 萬條消息而不會產生任何垃圾。現在使用 Intel i7 3.5GHz 機器超頻到 4.5GHz 的相同數字：
從
FixMessage到ByteBuffer- 每條消息平均 794 納秒。從
ByteBuffer到FixMessage- 每條消息平均 1.1 微。如果你想粗略估計吞吐量，你可以做數學：
吞吐量 = 1 秒（納秒）/（納秒以上時間）= 1,000,000,000 /（納秒以上時間）
但這會給您帶來不切實際的數字（> 100 萬 mps），因為它假設您的網路 I/O 時間為零。當您在網路 I/O 上花費微秒時，節省納秒的解析時間並沒有幫助。
因此，我們喜歡測量從網路讀取字節加上將字節解析為
FixMessage. 我們在這裡做了這個基準測試，數量是每秒從網路讀取和解析的 250k 修復消息。**免責聲明：**我是 CoralFIX 的開發者之一。
Fix8 在他們的網站上有一些基準測試結果。它們提供程式碼，因此您可以使用 FIX 引擎針對 Quickfix 或 Fix8 執行自己的基準測試。
