Embedded Files
這邊主角是 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架構改善
Report abuse