ComStock資訊應用

這邊主角是 CS_Top 這支程式

這裡簡介資訊流向與處理過程中的一些差異比較

展現優秀的平台下,不僅是架構完善,資訊即時有效率,更能於開發上作各種組合搭配

同時能於線上系統架構中,隨時能分出提供各種測試或研發的環境需求

1. 資訊流向

其中 A,B,C 三個項目對照 3. CS_Top 程式

A. 代表由ComStock接收資料共 83596KB, 透過 RawData 資訊架構傳輸僅須 47505KB, 壓縮比 56%

B. 代表同樣的資料,經由 DbfTS 系統傳輸則更縮減為只須 24456KB 與原始資料相比, 壓縮達 29%

C. 代表以ComStock原始資料提供傳輸給Telnet則須 83893403 Bytes也就是完全沒壓縮的 83596KB

不論是A,B,C任何一種皆為資料無損傳輸

2. TcpRDS使用ComStock資料Log作為資訊模擬,作本次分析( Log檔 1Cc(5).log , 80.0 MB (83,898,403 位元組) )

全檔播畢共有解出26212715個封包(以 ComStock DDF 格式計算)

Log檔大小, 與 CS_Top --> Telnet 的無壓縮傳輸一致, 共 83893403 Bytes

為縮短測試時間同時作壓力測試,最後是以資料流 320KB/sec 進行

3. CS_Top以TcpRDS為資訊源,提供資訊整合服務

CS_Top可提供頂端 DbfTS 的資訊架構(相當於DbfTS-Top), 也支援原始 DDF格式資料輸出,

同時能檢視各 Exchange下,依 Symbol 區別的 DDF 最新資訊內容, 並解釋出完整的報價資訊可供查詢

4. 連接 CS_Top 的第一層 DbfTS

以 RealTime Packet 處理,共接收有 461398 個封包, 1211個商品, 以格式化的類dbf檔案方式儲存共 289788 Bytes

這邊的封包數與原始 DDF 格式 26212715 相比僅原本的約 1.76%而已,

原因在於 <1C>c 這個 Exchange ID 的資料, DDF 送一個商品會用多達5個封包以上,

而透過 CS_Top 處理後, 會以商品為單位而只用一個封包傳達相同信息, 這中間已包含非商品信息的非必要資料過濾

5. 連接 DbfTS 的第二層 DbfTS

以類視頻方式同步資訊, 商品數 1211個是必然一致的, 共接收 460687 個封包, 較第一層傳輸略少

原因由於此資料分析是以 320KB/sec 的高速下進行的,

如果瞬間有同一商品重複更新,類視頻技術會直接傳輸該商品最新的完整訊息一次而已,這裡說的瞬間則依網路環境而異,

而這邊的網路環境是 Local, 所以有看到服務啟動失敗的訊息,因為兩個 DbfTS 程式於同一主機上使用相同的Port服務,

也因為網路環境是 Local(代表極佳),所以類視頻的效果看不太出來,基本上跟即時封包機制相差無異

6. Telnet 僅供對照比較

7. 當然,ComStock也有其先天上的設計缺陷,可透過DES架構改善