我先下載期交所的資料跑出來參考
2/9 逐筆
- ======= ::Program start: 17:15:52.311 =======
- *** (Daily_2018_02_09.csv) *** size: 23.13 MB 篩選商品: TX
- Total Tick Count: 475554 輸出方式[逐筆]
- [TX-201802] total volume 328566
- #Tick筆數: 184143 #寫檔筆數: 184143
- [TX-201802!201809] total volume 76
- #Tick筆數: 14 #寫檔筆數: 14
- [TX-201802!201803] total volume 29906
- #Tick筆數: 2803 #寫檔筆數: 2803
- [TX-201802!201806] total volume 284
- #Tick筆數: 15 #寫檔筆數: 15
- [TX-201802!201812] total volume 34
- #Tick筆數: 11 #寫檔筆數: 11
- [TX-201803] total volume 23661
- #Tick筆數: 17180 #寫檔筆數: 17180
- [TX-201806] total volume 1244
- #Tick筆數: 969 #寫檔筆數: 969
- [TX-201809] total volume 482
- #Tick筆數: 396 #寫檔筆數: 396
- [TX-201812] total volume 295
- #Tick筆數: 268 #寫檔筆數: 268
- ======= ::Program end : 17:15:54.094 =======
- ::Program timing: 1.78 sec(s)
複製代碼 2/9 同秒同價合併- ======= ::Program start: 17:17:21.623 =======
- *** (Daily_2018_02_09.csv) *** size: 23.13 MB 篩選商品: TX
- Total Tick Count: 475554 輸出方式[合併]
- [TX-201802] total volume 328566
- #Tick筆數: 184144 #寫檔筆數: 81754
- [TX-201802!201809] total volume 76
- #Tick筆數: 15 #寫檔筆數: 14
- [TX-201802!201803] total volume 29906
- #Tick筆數: 2804 #寫檔筆數: 2245
- [TX-201802!201806] total volume 284
- #Tick筆數: 16 #寫檔筆數: 8
- [TX-201802!201812] total volume 34
- #Tick筆數: 12 #寫檔筆數: 10
- [TX-201803] total volume 23661
- #Tick筆數: 17181 #寫檔筆數: 10499
- [TX-201806] total volume 1244
- #Tick筆數: 970 #寫檔筆數: 803
- [TX-201809] total volume 482
- #Tick筆數: 397 #寫檔筆數: 344
- [TX-201812] total volume 295
- #Tick筆數: 269 #寫檔筆數: 245
- ======= ::Program end : 17:17:23.213 =======
- ::Program timing: 1.59 sec(s)
複製代碼 3/6 逐筆
- ======= ::Program start: 17:15:24.670 =======
- *** (Daily_2018_03_06.csv) *** size: 12.28 MB 篩選商品: TX
- Total Tick Count: 252866 輸出方式[逐筆]
- [TX-201803] total volume 186255
- #Tick筆數: 91924 #寫檔筆數: 91924
- [TX-201803!201806] total volume 52
- #Tick筆數: 2 #寫檔筆數: 2
- [TX-201803!201804] total volume 46
- #Tick筆數: 10 #寫檔筆數: 10
- [TX-201803!201812] total volume 24
- #Tick筆數: 6 #寫檔筆數: 6
- [TX-201803!201809] total volume 16
- #Tick筆數: 8 #寫檔筆數: 8
- [TX-201804] total volume 3702
- #Tick筆數: 2633 #寫檔筆數: 2633
- [TX-201806] total volume 322
- #Tick筆數: 292 #寫檔筆數: 292
- [TX-201809] total volume 170
- #Tick筆數: 160 #寫檔筆數: 160
- [TX-201809!201812] total volume 42
- #Tick筆數: 1 #寫檔筆數: 1
- [TX-201812] total volume 128
- #Tick筆數: 117 #寫檔筆數: 117
- ======= ::Program end : 17:15:25.485 =======
- ::Program timing: 815.235 ms
複製代碼 3/6 同秒同價合併
- ======= ::Program start: 17:18:04.201 =======
- *** (Daily_2018_03_06.csv) *** size: 12.28 MB 篩選商品: TX
- Total Tick Count: 252866 輸出方式[合併]
- [TX-201803] total volume 186255
- #Tick筆數: 91925 #寫檔筆數: 39129
- [TX-201803!201806] total volume 52
- #Tick筆數: 3 #寫檔筆數: 2
- [TX-201803!201804] total volume 46
- #Tick筆數: 11 #寫檔筆數: 9
- [TX-201803!201812] total volume 24
- #Tick筆數: 7 #寫檔筆數: 3
- [TX-201803!201809] total volume 16
- #Tick筆數: 9 #寫檔筆數: 7
- [TX-201804] total volume 3702
- #Tick筆數: 2634 #寫檔筆數: 1853
- [TX-201806] total volume 322
- #Tick筆數: 293 #寫檔筆數: 252
- [TX-201809] total volume 170
- #Tick筆數: 161 #寫檔筆數: 153
- [TX-201809!201812] total volume 42
- #Tick筆數: 2 #寫檔筆數: 1
- [TX-201812] total volume 128
- #Tick筆數: 118 #寫檔筆數: 96
- ======= ::Program end : 17:18:04.934 =======
- ::Program timing: 732.911 ms
複製代碼
首先為了玩系統,所以架構故意弄的比較複雜
地點1: VM1(XP, 384MB ram) 跑API收資料篩選商品重新打到VM2
地點2: VM2(2K Server, 384MB ram), 於Host中再跑程式連到VM2上收資料存Tick紀錄
VM1的API是接收全部商品的資料,包含
TSE:全部的股票/權證/大盤/類股/指數等
OTC:全部的股票/權證/興櫃/櫃檯/類股/指數等
TFE:全部的現貨/期貨/期貨選擇權/股票選擇權等
其他:包含國際指數,摩台指/期貨等
由於就只想觀察一下台指的部分,
所以綁API的程式會篩選代碼有TX的TFE商品打到VM2
因此VM2就只剩TX,MTX,TXZ等商品
跑VM2的HOST上的接收程式也又只會紀錄VM2上有的商品而已
然後是資料筆數作觀察,
因為此API為ST公司的M系列,就表示為 API(ST/M)
群益的API,就表示為API(Capital) 吧
2/9台指日盤期交所有132805筆(同秒同價合併只剩53532筆)
API(ST/M) 91083 API(Capital)的有96000
3/6台指日盤期交所有68172筆(同秒同價合併只剩25335筆)
API(ST/M) 46424 API(Capital)的有47400
也就是API的部分明顯都有併筆的機制,既然都是要併筆
那就是看快市瞬間併筆的效率好還是差了,可能要切細去比較,
而ST/M的併筆之前就抓到他有個毛病,同價跨秒時的邏輯有點問題,
也可能是這部分多併了也有蠻大的影響
就架構而言,源頭接收機收資料併筆再打給前端服務器,
併筆的行為只需接收機上處理一次
跟我跑程式分析所有TFE的Tick明細是相同的,只是需瞬間處理更龐大的資料量
接收機則是整個盤間慢慢消化資料,
然後要處理用戶REQUEST REPLY的是前端服務器,它是不用併筆處理的
所以接收機會有併筆與轉格式和提供前端伺服器架構中通訊同步所有市場行情的工作
前端伺服器則是依格式Update轉發給有需求的用戶端
用戶端應該最輕鬆,看註冊那些商品指處理那些商品的Update(姑且不論策略與其他分析)
而用戶端LAG的原因在哪呢?
1.用戶端本身就有問題
2.前端服務器有問題
3.接收機就已經有問題
為何1. 用戶端快市時loading就衝高,
因為程式效能差阿,收的資料量遠不如前端伺服器和接收機,
接收機吃的下全市場行情,用戶端吃不下部分商品行情?
為何2. 前端伺服器快市時未必有高loading卻會有lag?
因為是TCP通訊,有一個用戶卡,Server的如果是同步的架構就大家一起等卡吧
接收機就不說了,自己用盤後資料測試壓力看看吧!!!!!
為何盤後相對有效率? 一般的設計
因為盤中一直收新資料而這些資料需要要求記憶體,
陸續增加記憶體用量的處理機制差,就效能差
這是不論接收機,前端服務程式或用戶端都會碰到相同情況
而盤後記憶體用量已固定,所以就沒有記憶體用量激增的處理邏輯
就像群益的用戶端盤後才上線回補大量Tick時也是會衝高loading,
多跑幾份就跟死了沒兩樣一樣的意思,都是資料一直在新增的處理效率問題
而有時候併筆是另有考量,為了省頻寬省記憶體用量
我跑盤後資料分析則是跟盤中記憶體越吃越大的運作方式是一樣的,
並不是預先留好足夠大的array方便存放資料來讓程式變的有效率,所以才會拿來比較,
而其中反而還得先模擬期交所把資料送出的樣子來打進去處理機制中運作
像是ST/M的API,不論08:45還是09:00從來沒有特別lag過
負載也都很低,VM1從2/6 00:00 跑起來 API只用CPU時間16小時,系統Idle則是690小時
API記憶體有超過6萬檔商品,tick不放記憶體,所以只需不到6MB的記憶體使用量
其實有很多可討論的部分,只是略提一些容易觀察到的
|