What-Can-Trade-Today (run in Heroku app and backup with Railway app)
- use BB strategy to check tickers
- BB strategy demo clip is on Google Drive now :
https://drive.google.com/file/d/1WIVBSOXXoSdfN-0M6hUhFN8FWXoG8EcR/view?usp=sharing
https://drive.google.com/file/d/1ZQqjkHx6O02Nn7fkRiaDMwwxnQw-4pbd/view?usp=sharing
- V1
- 條件:4845個ticker, ticker number in each batch=10, thread number=1, bb std=2,
- 結果:~=90分鐘(600張圖)
- 未來改善方向:
- 太慢,需提速
- V2
- 條件:4845個ticker, ticker number in each batch=10, thread number=3, bb std=2,
- 結果:~=47分鐘(600張圖),圖片異常,resp:429
- 更新項目:
- thread number=1,改為多執行續thread number=3處理
- 未來改善方向:
- matplotlib非線程安全,所以會有Race Condition,圖片才會異常,須逐個製圖(by queue or list)
- telegram 會擋過於頻繁的request(resp:429),須穩定依次發圖
- V3
- 條件:4845個ticker, ticker number in batch=100, thread number=5, bb std=3,
- 結果: ~=15分鐘(50張圖)
- 更新項目:
- std=2條件過於寬鬆,更改為std=3
- 429及製圖缺失大量減少,因為每批次執行數量提升,且bb std拉高,需製作及傳送的圖已大量減少,但仍需使用queue使系統更robust
- 未來改善方向:
- 多主機併行衍生議題
- 多執行續衍生議題
- 資料處理過程的中繼檔案過多
- V4
- 條件:4845個ticker, ticker number in batch=100, thread number=5, bb std=3,
- 結果:~=27分鐘(不含發圖),時間拉長,因為Redis連線次數增加
- 更新項目:
- 重構資料處理流程,減少中繼檔案數量
- 製圖模組重構,解決多執行續下的資源競爭問題
- 發圖模組重構,以便後續處理resp:429問題
- 多主機任務分派(免費版只執行選定ticker,自己的主機再執行所有ticker)
- railway測試,單次花費
- ENVIRONMENT參數決定哪台主機是master哪台主機是slave
- 未來改善方向:
- redis操作提速
- V5
- 條件:4845個ticker, ticker number in batch=100, thread number=5, bb std=3, LUA script
- 更新項目:
- Lua腳本處理狀態值改變(111->999),減少連線次數,並保證atomic,避免多執行續交互存取產生的髒資料
- redis連線測試,查尋及修改 in 100 loop
- 每個動作都取一次連線(100次連線後查詢+4845次連線後更新):~300s
- 取一次連線後執行查及改(1次連線+100次查詢+4845次更新):46s~91s
- 取一次連線後送LUA腳本(100次連線後執行LUA腳本):1s~5s
- 結果:~=19分鐘(12張圖),
- 未來改善方向:
- auto login your Etoro account
- switch to virtual portfolio
- open positions
https://drive.google.com/file/d/1a5LGwJYYAsmHQJFpWiJyKPtz2ni_J-fg/view?usp=sharing
- create a main page
- open position with a click
- close position with a click
- check positions with a click