nes 發表於 18-3-12 19:13

jerry 發表於 18-3-11 00:43
NES 大我剛下載您的資料 和我的比對後發現2/9
您收的台指日盤TICK只有91000 我收的有96000



我先下載期交所的資料跑出來參考
2/9 逐筆
======= ::Program start: 17:15:52.311 =======
*** (Daily_2018_02_09.csv) *** size: 23.13 MB 篩選商品: TX
Total Tick Count: 475554      輸出方式[逐筆]
total volume 328566
#Tick筆數:    184143    #寫檔筆數:    184143
total volume 76
#Tick筆數:      14    #寫檔筆數:      14
total volume 29906
#Tick筆數:      2803    #寫檔筆數:      2803
total volume 284
#Tick筆數:      15    #寫檔筆數:      15
total volume 34
#Tick筆數:      11    #寫檔筆數:      11
total volume 23661
#Tick筆數:   17180    #寫檔筆數:   17180
total volume 1244
#Tick筆數:       969    #寫檔筆數:       969
total volume 482
#Tick筆數:       396    #寫檔筆數:       396
total volume 295
#Tick筆數:       268    #寫檔筆數:       268

======= ::Programend : 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      輸出方式[合併]
total volume 328566
#Tick筆數:    184144    #寫檔筆數:   81754
total volume 76
#Tick筆數:      15    #寫檔筆數:      14
total volume 29906
#Tick筆數:      2804    #寫檔筆數:      2245
total volume 284
#Tick筆數:      16    #寫檔筆數:         8
total volume 34
#Tick筆數:      12    #寫檔筆數:      10
total volume 23661
#Tick筆數:   17181    #寫檔筆數:   10499
total volume 1244
#Tick筆數:       970    #寫檔筆數:       803
total volume 482
#Tick筆數:       397    #寫檔筆數:       344
total volume 295
#Tick筆數:       269    #寫檔筆數:       245

======= ::Programend : 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      輸出方式[逐筆]
total volume 186255
#Tick筆數:   91924    #寫檔筆數:   91924
total volume 52
#Tick筆數:         2    #寫檔筆數:         2
total volume 46
#Tick筆數:      10    #寫檔筆數:      10
total volume 24
#Tick筆數:         6    #寫檔筆數:         6
total volume 16
#Tick筆數:         8    #寫檔筆數:         8
total volume 3702
#Tick筆數:      2633    #寫檔筆數:      2633
total volume 322
#Tick筆數:       292    #寫檔筆數:       292
total volume 170
#Tick筆數:       160    #寫檔筆數:       160
total volume 42
#Tick筆數:         1    #寫檔筆數:         1
total volume 128
#Tick筆數:       117    #寫檔筆數:       117

======= ::Programend : 17:15:25.485 =======
::Program timing: 815.235 ms3/6 同秒同價合併
======= ::Program start: 17:18:04.201 =======
*** (Daily_2018_03_06.csv) *** size: 12.28 MB 篩選商品: TX
Total Tick Count: 252866      輸出方式[合併]
total volume 186255
#Tick筆數:   91925    #寫檔筆數:   39129
total volume 52
#Tick筆數:         3    #寫檔筆數:         2
total volume 46
#Tick筆數:      11    #寫檔筆數:         9
total volume 24
#Tick筆數:         7    #寫檔筆數:         3
total volume 16
#Tick筆數:         9    #寫檔筆數:         7
total volume 3702
#Tick筆數:      2634    #寫檔筆數:      1853
total volume 322
#Tick筆數:       293    #寫檔筆數:       252
total volume 170
#Tick筆數:       161    #寫檔筆數:       153
total volume 42
#Tick筆數:         2    #寫檔筆數:         1
total volume 128
#Tick筆數:       118    #寫檔筆數:      96

======= ::Programend : 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的記憶體使用量

其實有很多可討論的部分,只是略提一些容易觀察到的
















jackaitw 發表於 18-3-13 10:49

謝謝nes大,那我也來改用你的程式下載。

ram 發表於 18-3-13 12:42

jackaitw 發表於 18-3-13 10:49
謝謝nes大,那我也來改用你的程式下載。

請教jack大,程式在哪阿,翻了好久都沒看到阿{:4_186:}

ram 發表於 18-3-13 15:21

jackaitw 發表於 18-3-9 19:12
nes大我是用ocelot.exe下載的,這隻程式是底下這篇文章提供的,但是現在這篇文章卻上不去了所以不知道這 ...

錯誤訊息好像證交所的部分不是期交所的
我證交所以前放書籤的連結都會出現以下訊息

您好:

本公司全球資訊網已於106年5月23日改版,您目前瀏覽使用的網址並不正確,建議您自首頁(www_twse_com_tw)重新瀏覽,並更新瀏覽器「我的最愛」或「書籤」設定。

如須進一步協助請參閱本公司官網改版問答集(www_twse_com_tw/downloads/zh/home/TWSE_QA.pdf),或洽投資人服務中心專線:(02)2792-8188
錯誤代碼為:N/A
事件代碼為:62855323337778151

TWSE revised the official website on 23rd May, 2017. The URL address you were trying to reach seem to be incorrect or outdated. Please update your browser bookmark(s), thank you.

TWSE official website: www_twse_com_tw
Page Error Code:N/A
Event ID:62855323337778151

jackaitw 發表於 18-3-14 17:16

ram 發表於 18-3-13 12:42
請教jack大,程式在哪阿,翻了好久都沒看到阿

ram大,我看錯了,我下載TickData.part01.rar,TickData.part02.rar,TickData.part03.rar,回來解壓縮之後才發現這不是下載程式。
{:4_186:}

nes 發表於 18-3-26 10:04

本帖最後由 nes 於 18-3-26 10:10 編輯

jackaitw 發表於 18-3-14 17:16
ram大,我看錯了,我下載TickData.part01.rar,TickData.part02.rar,TickData.part03.rar,回來解壓縮之 ...
上來看到有這樣的需求... 也是醉了~
應用期交所的資料大概分成三個步驟
1. 下載 ... 網路上有很多下載的工具可以使用
2. 解壓縮 ... 網路上有很多解壓縮的工具可以使用
3. 轉資料 ... 這邊才是大家要依自己的需求來作處理的是吧!

既然提到下載,就上傳一個網路上找的小工具


這個HttpDL-TFE.exe執行檔
直接執行的話就是下載當天日期檔名的Tick檔
例如今天2018-03-26
就是下載 期交所網站的 /DailyDownload/DailyDownloadCSV/Daily_2018_03_26.zip
存在本地執行環境下的檔名就是 Daily_2018_03_26.zip

程式有三個隱藏參數可以用
/out 可以改變存檔名稱
例如執行時加參數
HttpDL-TFE /out csv.zip
這樣前面的的執行結果就變成本地存檔的檔名是 csv.zip

/url 可以改變下載的網址
例如執行時加參數
HttpDL-TFE /out csv.zip /url /DailyDownload/DailyDownloadCSV/Daily_2018_03_22.zip
就變成是下載2018-03-22的Tick檔存檔於本地為檔名 csv.zip

/host 則是可以改變網站的HOST
例如執行時加參數
HttpDL-TFE /host 61.222.218.201
這樣執行結果會跟沒下參數是一樣的...
因為 www.taifex.com.tw 的IP就是61.222.218.201

程式有下載到資料執行結果是1,否則是0
所以寫批次檔可以這樣寫
run1.bat內容
HttpDL-TFE /host 127.0.0.1
if ERRORLEVEL 1 echo "success"這樣就會發現 "success" 不會echo出來

因為改連127.0.0.1下載不到資料

反之如果
run2.bat內容為
HttpDL-TFE /out MyCsv.zip
if ERRORLEVEL 1 echo "success"執行就會出現echo "success" 的結果


這個程式的缺點就是只能下載HTTP,如果變成HTTPS就不能用了!
另一個限制是只能下載檔案大小於8MB以內的
但是程式很小,不需要任何額外的資源就能執行
而因為能改變HOST和URL
所以除了期交所也可用於下載其他地方的檔案


jackaitw 發表於 18-3-28 15:32

nes 發表於 18-3-26 10:04
上來看到有這樣的需求... 也是醉了~
應用期交所的資料大概分成三個步驟
1. 下載 ... 網路上有很多下載的工 ...

感謝nes大,呵呵,想不到有此意外收穫,太棒了。

ram 發表於 18-3-28 23:59

nes 發表於 18-3-26 10:04
上來看到有這樣的需求... 也是醉了~
應用期交所的資料大概分成三個步驟
1. 下載 ... 網路上有很多下載的工 ...

小巧又實用而且容易搭配 讚!讚!讚!
但是拿去下載SGX的資料時發現不行
後來才注意到原來是有限制8MB
SGX的WEBPXTICK_DT-20180327.zip檔案基本是都是超過10多MB以上
相比國內資料真的是好小阿{:4_169:}


nes 發表於 18-4-3 11:09

ram 發表於 18-3-28 23:59
小巧又實用而且容易搭配 讚!讚!讚!
但是拿去下載SGX的資料時發現不行
後來才注意到原來是有限制8MB


不是喔!SGX另外有下載程式

跟TFE一樣有/out /url /host參數可以下
不過SGX跟TFE實際用法可能不一樣
可以看

zip檔的連結有一個F參數像下面20180402的資料則是F=4079
Apps?A=COW_Tickdownload_Content&B=TimeSalesData&F=4079&G=WEBPXTICK_DT-20180402.zip所以自己要弄/url的話麻煩在F=多少的問題

不過這支SGX下載的程式可以直接執行
就會下載前面頁面中列表裡最新的一個料檔

然後他有 /key 和 /date 參數可以用
/key是用來指定剛剛的F參數
/date則是用來指定要下載的資料檔日期
例如知道20180321的key是4070就能這樣下
HttpDL-SGX /out MyCsv.zip /key 4070 /date 20180321所以網頁列表中沒看到的歷史資料,如果知道key就還是能下載到

圖中可以看到也是有資料小於10MB的喔!

SGX版跟TFE一樣,批次檔裏可以用ERRORLEVEL判斷是否有下載成功
所以我的用法是記憶一個key值
用當前的日期如果下載成功則key累加1...日復一日批次進行

反過來用,透過一組date與key陸續遞減
或許也真的可以把SGX有史以來4千多天交易日的所有歷史資料都下載回來...
但是台北對SGX的下載速度很慢,實在沒耐性作這種事

假如把SGX版的程式拿去下載烏魯木齊的資料
當下載超過32MB的資料檔失敗時就會出現提示
那麼就會發現原來還有一個/buf參數可以用
因此若有需要要下載更大的資料檔就可以用這個參數作調整了
例如前面SGX的下載如果加了參數 /buf 5 就會下載失敗了(資料9MB>設定5MB)

現在很多工具都很龐大,然後動不動就要搭NET,
不然就是較新的Win10上要跑常常就出現沒有MSVCxxx.dll的訊息不能跑,
雖然也有會出現訊息但是好像一樣可以正常運作的...(但這不是很莫名其妙嗎)
所以個人看到這種小巧的批次檔案工具程式總是特別喜愛收藏


ram 發表於 18-4-6 10:31

nes 發表於 18-4-3 11:09
不是喔!SGX另外有下載程式

跟TFE一樣有/out /url /host參數可以下


感覺下載雖然慢,但是用瀏覽器下載也是慢
瀏覽器下載還常常會直接因為太慢而斷掉失敗
反而用程式很穩,可惜無法知道下載進度
不過放批次的話應該不不會在意下載進度

ndc24075 發表於 18-4-22 22:54

想不到api的差異會這麼大...

ram 發表於 18-5-1 18:22

nes 發表於 18-4-3 11:09
不是喔!SGX另外有下載程式

跟TFE一樣有/out /url /host參數可以下


SGX的下載程式有個問題

我在往前推key下載舊的檔案過程中發現
如果檔案不存在還是會下載到檔案,只是檔案很小,不到2KB
仔細查看下載到的內容實際上是HTML
這樣想在批次檔中用ERRORLEVEL判斷下載結果的話就行不通

想請教一下nes大是怎麼處理的{:4_144:}




ram 發表於 18-5-20 13:13

ram 發表於 18-5-1 18:22
SGX的下載程式有個問題

我在往前推key下載舊的檔案過程中發現


小弟不才,用DevC++寫了個小小程式解決了SGX下載到HTML的問題


程式碼和執行檔

也就是寫了一個main.exe去呼叫HttpDL-SGX.exe
如果下載檔案的長度過小就當作失敗
例如

main 4113 20180517
就會下載失敗==> ERRORLEVEL 0

main 4112 20180517
就會下載成功==> ERRORLEVEL 1

跟剛看過的元大SmartAPI好像是異曲同工之妙阿!
也就是只要會寫exe,那麼R和Pyson就能調用阿
套一句元大手冊的說法
『事實上不止R、Python可以調用,任何具備呼叫外部指令的程式語言均可使用,是一個通用的框架。

說實話,快笑翻了我

而且元大原本API的問題沒解決的話,SmartAPI仍然會有一樣的問題會發生,
好處則是如果有合適的方法可以解決問題,那麼可於寫exe程式時把方法套進去弄好成符合期待


頁: 1 2 [3]
查看完整版本: 關於台指期的成交Tick的筆數