2020年12月26日 星期六

2020年投資績效報告

今年因為肺炎大流行的關係, 整個投資市場震盪的超可怕, 不過因為後期美國政府無限QE大撒幣, 所以即便經濟沒回來, 股市卻也因為這些熱錢狂漲, 然後這波行情大多反應在科技股上面, 這次疫情重壓金融股的我反而沒撿到什麼甜頭, 雖然當初撿金融股的時候就有長抱兩年以上的打算, 不過內心還是有點小不是滋味QQ

下圖是今年年初到12/25的績效表現, 首先是MWR (金錢加權回報率)



以MWR來計算今年績效有11.52%, 不過會有這數字主要是今年有解了一張美金定存保單, 以及把台幣存款拿來加碼才有這數字, 如果看TWR (時間加權回報率), 績效就低的可憐 (2%):



雖然今年的績效這樣看很差, 不過該說幸好去年績效超好, 再加上有把定存拿來加碼的關係, 所以雖然看%數不怎樣, 可是只看收益金額的話其實有賺到去年的一半, 實際看到報表時有嚇了一跳, 深刻的感受到滾雪球的威力是如此的美妙~。

今年的美股大盤指數相比, 道瓊工業表現最差只有5.82%, 標準普爾500則是14.62%, 而科技股指數的那斯達克指數以及費城半導體則是超可怕, 分別有42.71%以及48.69%的漲幅, 以疫情來說雖然帶動了不少科技產業的成長, 不過個人來說還是覺得這漲幅太嚇人了, 尤其是某些科技股漲到本益比幾百甚至破千的, 用常識就覺得這已經不理性到一個極致, 畢竟一家公司到底要成長多快才有辦法趕上那極高的本益比阿... 比起靠營收成長去追上本益比, 股價之後回檔到合理價位可能性還比較大, 不過說是這麼說, 其實是自己不敢買這種高本益比的個股, 所以也就賺不到這種飆股行情了...。



再來直接看今年跟大盤的績效比較圖(TWR), 可以看到今年最慘時績效甚至到-40%:


績效會這麼差主要有幾個原因:

1. 3月股災來的時候, 有近9成的持股全部跌破停損, 而跌破停損後沒幾天因為大盤又飛快漲回去, 就很樂觀的覺得會V型反轉, 然後那時候跌最慘的就屬金融股, 就撿了一堆便宜的金融股, 結果沒想到那時覺得撿到便宜的金融股股價連半山腰都算不上, 雖然撿了便宜10%~20%的金融股, 然而那堆金融股最後有些卻跌了超過50%以上, 這代表至少要漲100%以上才會持平, 導致我的整個投資部位績效虧損一度達到40%。

2. 因為自己的投資方式一直以來都是找好公司撿便宜, 而且都是有閒錢就買好買滿, 今年這波疫情下我也還是一樣完全不留任何現金, 還分別在2、3、 5、 9月從台灣匯錢加碼, 結果加碼的時間點有一半都在最糟的地方(不過實際上我也不會預知未來, 不知道哪個時間點才是好的加碼點, 就像現在明明疫情還是很嚴重, 美股卻依然創新高...)。

不過說實在的, 就算加碼在糟糕的地方, 唯一的欣慰就是我沒有被反覆割韭菜, 因為我相信自己買的公司體質很好, 雖然會因為疫情跟政府政策減少收益 & 虧損一陣子, 可是只要疫情結束, 公司轉虧為盈時, 股價會有很高的機率回到疫情前的水準。

另外雖然看起來今年是賺錢的, 可是實際上因為美國大撒幣, 導致美金對台幣狂跌, 今年的匯率跌了快7%, 所以賺的美金還要算上這些匯損, 不過以我來說其實算還好, 因為我本來就打算只有退休的那天才會把美金匯回台幣, 不如說現在美金便宜更是好機會, 讓我有更多加碼的空間!!



最後原本想貼上這一整年的交易清單, 可是發現清單太長了..., 以過去來說, 我只會持有4~6檔個股做分散風險, 可是今年因為疫情的關係市場波動超大, 今年為了分散風險我改持有了10~15檔個股, 雖然因為這樣可以讓非系統性風險降低, 可是金融股大跌那時屬於系統性風險, 所以有分散跟沒分散根本差不多, 不過那時就是金融股最便宜也只想買金融股, 只能說沒辦法嗎...XD

另外因為持有的標的變多了, 所以要關注自己的投資部位就得花更多時間, 為了省這些時間今年反而做了不少幫助自己快速檢視持有跟關注個股的網站, 因為這樣做了不少有用的工具, 算是因禍得福吧~。 有興趣的話也可以參考一下, 雖然個人網站那塊的部分都是只做給我自己看的就是了~

個人持有 & 關注清單: https://project.zmcx16.moe/?page=investment-stocks

凱利公式 & 個股績效: https://project.zmcx16.moe/?page=investment-formula

美股搜尋過濾網站: https://norn-stockscreener.zmcx16.moe/


希望這次的疫情可以早日平息。


2020年12月25日 星期五

[網站開發] 美股搜尋網站 Norn-StockScreener 加入Cache改善查詢效能

上次的開發心得:

[網站開發] 美股搜尋網站 Norn-StockScreener Ver1.0 Release

這次主要是幫後端程式加上cache, 這樣就不用每次查詢都要跑去DB問一次, 查詢時就直接從cache做條件過濾就好。 而cache的更新則是透過background thread每30分鐘去query DB更新cache, 雖然跟之前的查詢結果相比會有最多30分鐘的資料更新落差, 可是我的爬蟲跑完所有美股資料本來就要花上半天左右, 多個30分鐘的落差去換取使用者體驗還有DB查詢的負擔, 個人覺得是非常划算的! (畢竟以常理來說, 後端伺服器程式本來就不應該頻繁去DB查詢, 而是資料能存到cache就盡可能存cache, cache沒有或是資料庫有更新時在更新cache就好。)

決定好要加Cache之後, 再來就是想該怎麼實作了, 說到Cache第一個想到的就是火紅的Redis, 原本想說終於有機會可以開始玩Redis了, 可是研究下後發現, 覺得Redis並不適合用在我這個網站上, 原因有以下:

1. Redis本質上就是個cache server, 以cache的需求來說是非常強大的, 而且還支援簡單的query查詢, 可是他本質上依然不是DB, 不能做到NoSQL的各種查詢功能, 當然要做成類SQL查詢的cache table還是做得到的, 可是基本上就是做一堆reverse mapping table, 下面這篇就有教學怎麼設計Redis的cache table來做到SQL查詢:

How to get SQL-like Experience with Redis?

以上面的例子來說, 等於一個where條件我就要多做一個reverse mapping table, 而以stock screener來說幾乎是滿滿的過濾條件, 要做這麼大堆的reverse mapping table根本不划算, 除非今天我需要存到cache的物件很大, 用這種方式才划算, 以stock screener來說整個物件大小幾乎就等於過濾參數, 做這個感覺就撿不到便宜。

2. Redis基本上有需要用到的地方是可以水平擴展跨機器的程式, 讓所有程式都能共用 & 修改cache資料, 可是我的後端程式只放在一台VM上, 應該也沒有水平擴展的需求(畢竟要+機器就要要多花錢...), 如果是都在同一台機器上的process / thread需要共用cache的話, 那做shared memory就好, 根本沒有Redis出馬的必要阿...。

綜上所述, 就決定Cache直接用shared memory了, 而做法也很簡單, 後端伺服程式起來後就去跟Cosmos DB要資料, 然後存成JSON Array到記憶體裡, 之後有個background thread會每三十分鐘去跟DB更新cache, 而網頁前端打來的query資料則是直接用記憶體內的JSON Array做Linq查詢, 在吐回結果就好。

下面是有用cache跟每次去DB query的unit test比較結果, 48筆unit test沒有用cache要花1分53秒才跑完, 而有用cache則只要3秒就跑完了, 跟預期的一樣不用每次去query DB果然改善很多。


Cache的部分做完後, 還有些地方是需要設定的:

1. IIS的web application是會idle timeout以及regular recycling, idle timeout預設是20分鐘, 等於20分鐘沒有request那process就會直接停掉, 下次第一筆request就得等process起來 + 從DB讀資料, recycling的問題也一樣。

為了解決這問題, 這邊將設定改成6小時, 這樣至少process可以活6小時, 不改太大是怕IIS一直不recycling怕會有什麼奇怪的問題發生。 至於6小時後該怎麼辦, 這邊我是直接搭配freshping網站服務, 這個網站可以讓你設定50個網站, 然後他會每5分鐘幫你打一次request幫你檢驗網站是否正常工作, 搭配這服務我可以讓我的IIS網站就算idle太久而睡著, 也會在5分鐘以內被喚醒並更新cache。



2. 另外測試了一下, 從DB取得所有的個股資料大概要花1.7秒左右, 而這段更新cache的資料是得被lock保護的, 這代表使用者在query時如果撞到每30分鐘更新cache的時機的話, 會被那1.7秒卡住, 雖然1.7秒也不會說很長, 不過還是想解決這問題。 

至於想到的解決辦法也很簡單, 我就直接做兩份cache就好, 然後用一個flag去切換, 這樣cache更新跟使用者查詢用到的cache就不相同, 我只要lock保護那個flag就好, 這樣使用者就不用去花時間等待cache更新的時間, 畢竟切flag連1ms都不需要XD

這次更新就做到這邊, 下次更新應該是Google Play Store上架APP的部分, 目前網站的TWA App已經做好並提交到Google Play Store了, 就等審核結果如何~。

2020年12月20日 星期日

[網站開發] 美股搜尋網站 Norn-StockScreener Ver1.0 Release

上次的開發心得:

[網站開發] 美股搜尋網站 (1) 後端程式開發 - 使用Azure Cosmos DB & Azure Function

在上次的開發心得提到美股資料取得&每天更新資料庫的部分, 今天這篇則是把接Cosmos DB的後端程式 & 前端第一版做完了, 完成的成果如下:


Dark mode:



Mobile:



Norn-StockScreener網站位址:

https://norn-stockscreener.zmcx16.moe/


Github (Front-End):

https://github.com/zmcx16/Norn-StockScreener


搜尋功能主要包含了45個基本參數的過濾條件, 還有串接之前做的Norn-Minehunter美股健診網站, 畢竟這網站的開發初衷就是要滿足我的個人需求, 如果只有基本參數的過濾那我用現成的Stock Screener就好, 當初會想做這網站就是每次都要分開比對搜尋結果很麻煩, 才會想做一個滿足自己所有需求的網站!

在來會分別介紹後端跟前端的開發心得:


* 後端Server程式 *

基本上就是個簡單的資料庫查詢功能, 前端把UI的setting帶下來, 後端Server做Input檢查後就動態組成SQL搜尋條件, 再直接Query Azure Cosmos DB, 第一版就是先簡單實作有滿足功能就好。 至於測試方面則是只有針對每個過濾條件寫UT, 複合條件只有靠手測測個幾條, 畢竟這種搭配組合根本不可能靠UT或手測測得完...。

另外跟以往不同的是, 原本Server程式是想照慣例放到自己的Azure VM上, 可是那個VM只是一個月500塊的Azure B1S, 記憶體只有1G, 而且上面已經塞了5個web應用程式了..., 目前測試如果直接從DB拉所有股票資料, 程式的記憶體大概會耗到幾百MB, 這樣那台VM應該很容易就廢了, 還會連帶影響其他的應用程式...。

考慮到上述原因, 決定測試一下裝在Azure Function上, 畢竟Azure Function有每個月一百萬次呼叫以及40萬GB-s記憶體用量的免費額度, 應該是不至於超標, 缺點就是變成前端直連後端的Azure Function, 這樣要是遇到惡意的DDOS或爬蟲就沒辦法處理, 這部分就決定先觀察看看, 如果真的遇到了, 就再搬到自己的Server或開個新的Azure web service上了。

[後來簡單測試了一下, 發現Azure Function第一次觸發的暖機時間太長了(大概5s~15s), 決定還是先裝在自己VM的web server上, 在視情況看要不要調整spec...。]


* 前端UI *

UI的部分是用React寫的, 這已經是第三個用React寫的side project了, 不過每次寫都還是覺得自己會踩到不少雷, 而且因為寫的都是小的side project, 所以感覺自己的技術都不太有長進, 也沒有享受到React在大型應用程式上的好處, 最大享受到的好處大概就是像Material-UI這類的UI元件庫超豐富, 讓我幾乎不會有想要手刻UI元件的想法XD

說到Material-UI, 讓我最驚豔的是Material-UI的theme直接就有支援dark mode, 如果你的UI style都是用Material-UI的調色盤跟theme, 那只要直接切換theme type從light->dark就可以直接幫你底下的元件都轉成dark mode配色, 可是如果你有元件是自己寫死css的color以及background, 因為沒有Material-UI調色盤的對比跟增強色, 他當然就沒辦法幫你轉換dark mode適用的顏色, 你就得針對這些元件處理dark mode配色。

因為我大多數都是用Material-UI的調色盤, 而少數自訂義的css部分, 因為我對色彩學不熟, 我是乾脆直接用最簡單的做法, 直接在設定顏色時就調透明度, 這樣就算轉成dark mode原本設定的顏色違和感也不會太重, 算是一種取巧的做法~。


* 接下來的計畫 *

目前還有想到不少feature是想要做的, 條列如下:

1. 將網站直接做成手機App

直接把網站搬到手機App簡單來說就是PWA, 不知道PWA的可以參考以下這篇:

30 天 Progressive Web App 學習筆記 - 為什麼需要 PWA?

基本上PWA就是網站+基本預安裝讓手機瀏覽該網站有類App的使用體驗, 而近兩年微軟跟Google則是合作推出了TWA, 讓你的網站能真正包裝成app, 並上架到Google Store上! 不過要上架得滿足不少條件, 首先就是至少你的網站要先滿足PWA的規範才行。

要確定網站是否滿足PWA規範, 可以用Lighthouse這個工具, 可以直接幫你體檢你的網站的效能跟使用者體驗, 以及是否滿足PWA的基本需求, 下面是Norn-StockScreener測試的結果:


效能的評分結果不太好, 主要原因是我的React元件太多, 畢竟光是基本過濾參數就有45組了, 這邊要改善的話, 可以把讓網站不要一口氣讀取所有元件, 把過濾參數做成Basic跟Advanced兩種, 網頁讀取時只先render basic的元件就好。 而除了效能指標之外, 再來就是PWA的需求有沒有滿足:


從上述來看, 缺的都是以在mobile app上運作需要的功能, 像是網站離線連不到時offline可運行的模式, 還有可遮罩式icon等等, 值得高興的是, 像是CreateReact的樣板或是gastby都已經有現成的套件可用, 如果沒有特殊的客製化需求, 只要安裝對應的套件在設定一下config就行了, 如果要不靠套件從頭自己搞八成又得花大把時間了, 真是萬萬歲XD  設定好以後再跑一次Lighthouse, 順利取得了PWA徽章, 完成上架Google Store的第一步了! 剩下的步驟就之後慢慢搞定吧~。



2. 增加Tag功能

目前的網站功能只有基本參數過濾以及Norn-Minehunter掃雷過濾, 再來會想做些Popular Tag的功能, 像是有產業別的tag可以選, 點擊後就能導到該產業別的美股基本&比較資料; 還有像是各大基金持股Tag這類特殊功能, 每種Tag都會導到對應功能的summary頁面, 這塊算是一個超級大的feature, 之後打算針對自己的需求慢慢implement (最近有點太操, 步調要緩一緩XD)


3. 後端Server效能改善

目前只要網頁按Query按紐, 後端Server都會去DB查詢, 可是大多數的Stock Screener網站的搜尋結果都超快, 我在想應該是他們都有做cache, 然後query等過濾條件都在memory裡做掉了, 後端Server只要大概每15分~30分鐘去跟DB拿更新的所有個股資料到記憶體就好, Query本身不需要去問DB, 這塊想之後有空就實作進去(想暫時耍廢一陣子先~)。


這次的開發經驗就分享到這, 再來工作應該會很忙, 希望有餘力能繼續完成上面的future tasks~。


2020年12月19日 星期六

MahoMangaDownloaderVer13.3更新

有使用者反應最近幾天有些網站無法下載, 看log訊息應該是網站的server強制要求SSL要TLS1.2以上, 因為.net webclient預設沒有開, 之前遇到這情況都是by網站加設定, 趁這次更新想說就乾脆改成全部都吃TLS1.2設定了~。

Ver13.3 更新內容:

* 修復一些網站修改SSL限制導致不能下載問題


下載器Demo圖:




介紹:

https://project.zmcx16.moe/?page=mahomangadownloader


MahoMangaDownloader下載器主要為幫助使用者改善線上漫畫的閱覽體驗, 如果試看的漫畫您非常喜歡, 也請麻煩購買正版支持原作者, 讓作家們能繼續創造出下一部更棒的作品。


環境需求

.Net framework 4.5.2或以上的版本

Visual C++ 2015 (只能安裝2015版, 其他版本不行)


簡單除錯:

* 如果下載失敗, 麻煩先用瀏覽器測試看資源是否存活。

* 如果能正常用瀏覽器瀏覽, 麻煩先查看LogFiles資料夾內的log檔案看錯誤訊息為何。

* 回報問題時, 麻煩提供有問題的網址以及log內容, 這樣我才有辦法測試找問題原因。


檔案位址:

https://drive.google.com/file/d/1ip_QRVys16dSn9cgLO-f54-mL6j0XRsZ/view?usp=sharing


32位元版本:

https://drive.google.com/file/d/1LsQ3ivMbH2mFR_NN2ldf8MOWHtEJdRJf/view?usp=sharing


解壓密碼:zmcx16


免責聲明:

******************

MahoMangaDownloader僅作為學術研究使用,禁止利用本程式行非法用途。

2020年12月1日 星期二

MahoMangaDownloaderVer13.2更新

這次更新主要是使用者回報漫畫唄改網域名了, 算是這次已經是第三次改網域名了, 不得不說有點頻繁阿..., 不過基本上改網域名我也只是改一行code, 所以也是還好啦, 只是發更新文就省不了功夫了QQ


Ver13.2 更新內容:

* 修復漫畫唄改網域名導致不能下載問題 (www.manhuabei.com -> www.manhuadai.com)


下載器Demo圖:




介紹:

https://project.zmcx16.moe/?page=mahomangadownloader


MahoMangaDownloader下載器主要為幫助使用者改善線上漫畫的閱覽體驗, 如果試看的漫畫您非常喜歡, 也請麻煩購買正版支持原作者, 讓作家們能繼續創造出下一部更棒的作品。


環境需求

.Net framework 4.5.2或以上的版本

Visual C++ 2015 (只能安裝2015版, 其他版本不行)


簡單除錯:

* 如果下載失敗, 麻煩先用瀏覽器測試看資源是否存活。

* 如果能正常用瀏覽器瀏覽, 麻煩先查看LogFiles資料夾內的log檔案看錯誤訊息為何。

* 回報問題時, 麻煩提供有問題的網址以及log內容, 這樣我才有辦法測試找問題原因。


檔案位址:

https://drive.google.com/file/d/1I5Hfyq5gQoFbdmd6de_BXddCVaW4x2Kq/view?usp=sharing


32位元版本:

https://drive.google.com/file/d/11hWafkgAQ3P1QdneX8abumnr3eCNv_MN/view?usp=sharing


解壓密碼:zmcx16


免責聲明:

******************

MahoMangaDownloader僅作為學術研究使用,禁止利用本程式行非法用途。

2020年11月23日 星期一

[網站開發] 美股搜尋網站 (1) 後端程式開發 - 使用Azure Cosmos DB & Azure Function

去年自己寫了個美股掃雷網: https://norn-minehunter.zmcx16.moe/

至於選股則是都透過Finviz的screener功能: https://finviz.com/screener.ashx?v=111&ft=4

雖然說Finviz真的很好用, 功能也非常強大, 可是能看的東西都是已知的基本面或技術分析指標, 沒辦法做自己的客製化指標, 變成我每次都得先用Finviz的screener先搜尋過濾, 在用自己的指標挑選一次, 這樣很麻煩又會有缺漏, 就想說還是自己來做個美股搜尋器好了。

再來就是做搜尋器最大的問題點了, 我要怎麼取得所有美股的數據資料? 美股大概有一萬檔以上的上市股票, 扣掉市值太低以及成交量太低的個股, 也還是有近3000~6000檔個股。 而我目前使用的數據源都是免費的, 只要使用量太大就會被ban IP, 如果乖乖的在不被ban IP的情況去取得所有美股資料的話, 目前估算抓完一輪至少要一個多禮拜, 這樣每次過濾搜尋的資料會離得目前市價太遠, 會有工具失真的問題...。

以自己來說要達到搜尋器可用等級的話, 數據資料最多不能差超過一天, 所以我至少要有7個IP以上每天不斷的抓數據才有辦法, 幸好之後有想到辦法, 詳情可以參考以下這篇:

[雲端服務] 被ban ip又沒有穩定的proxy server怎麼辦? 用Azure Function自己架個代理伺服器吧

Ban IP的問題解決了, 再來就是伺服器工作量的問題, 基本上就是要寫個一直取得美股數據並生成報表的程式, 由於自己的Azure VM是最低階規格, 而且已經掛了幾個我的網站服務, 所以就不太想把這個一直忙跟佔網路流量的程式放在自己的Azure VM server上了。思考了下最後決定把這個程式寫在Azure Function上, 像這種 I/O bound的工作放在Azure Function可以幾乎花不到什麼錢, 至於取得的數據部分, 原本是想直接上傳到我自己的Azure VM上或是存到Azure storage account, 不過剛好最近玩Azure時有注意到他們的Azure Cosmos DB的免費層還蠻佛心的, 剛好又想玩玩NoSQL, 就決定趁這次機會玩玩看。

下面是Azure Cosmos DB免費層規格:


RU是request unit的縮寫, 認真講還真看不懂要怎麼換算, 不過以容量來說有5G已經很佛心了, 而container則是有限制最多只能開到25個, 以我來說算綽綽有餘了。 另外由於Azure Cosmos DB分片是以10G為單位, 以免費層來說等於不會有用到分片的機會, 沒辦法享受到NoSQL水平擴展的魅力。

建好的DB概觀圖如下, 目前正在用Azure Function慢慢抓資料放到DB中, 這資料跟索引大小的比例真是讓人愉悅XD



下圖是Azure Cosmos DB的資料總管, 可以直接從網頁看到你的資料庫內容, 目前我主要拿來放每檔美股的基本以及生成掃雷報表的分數結果, 不過因為容量只有5G, 基本上也沒有這個key的表現機會就是了。 另外從圖中可以看到, 資料是以JSON表示, 另外Azure也很貼心的提供SQL command支援, 不過畢竟是NoSQL, 已經不是關聯式資料庫了, 應該還是有些語法不支援吧, 這個就有空在研究了。 另外很可惜的是Azure Cosmos DB免費層不支援VNet, 這代表我沒辦法設定防火牆只讓我的Azure入口網站還有Azure Function存取, 只能用Authorization Key當作最終保護DB的手段。



基本上都是用async的function讀寫, 寫入的時候都會指定你資料的Partition Key, 另外奇怪的是範例上的讀寫資料都是用自己寫的class定義document的結構, 在讓SDK把資料轉入 / 出 定義好的class物件, 基本上這樣超麻煩..., 畢竟這等於每種類型的document都得寫個class去定義schema, 這樣跟關聯式資料庫時定義schema不是沒兩樣嗎..., 如果是多層的json資料不是會寫到死, 更何況json還有可能是動態的, 如果圖方便用字串存那之後query又得去parser字串效能不就悲劇了嗎?

因為範例那種作法超麻煩, 所以我自己是把有可能是動態的資料都直接宣告成dynamic了, 而且這樣寫進去的資料從Azure資料總管看也是多階層的JSON, 而讀取的話我是直接用dynamic去接, 在用JSON parser去parse我要的資料, 這樣效能應該是會比自己定義class去存取慢, 不過基本上不用在意效能的地方很方便就是了, 不如說有可能動態階層的document也只能這樣讀吧?



這次分享就到這邊, 基本上後端這樣就搞定了, 再來就是苦力的前端, 基本上大多數網站的Stock Screener的頁面都大同小異, 應該是不用花太多心力刻啦, 不過我自己每次寫前端都覺得超累, 不像後端寫好功能邏輯就好, 前端layout跟微調每次都得花大把時間, 可以的話能不寫還真想不寫XD

2020年11月22日 星期日

[雲端服務] 被ban ip又沒有穩定的proxy server怎麼辦? 用Azure Function自己架個代理伺服器吧

由於自己之前做的掃雷網會用到YAHOO財經API, 而YAHOO財經API是有限制的, 只要你一分鐘內打太多request, 就會被ban ip大概幾分鐘左右。 由於這個限制, 所以如果我想從YAHOO拿到所有美股的資料的話, 扣掉市值跟成交量太小的個股至少也要花一個多禮拜才有辦法拿到所有資料。

要解決這個問題, 一個就是買YAHOO財經的付費數據源, 不過那個夭壽貴也用不到那麼多功能, 所以不考慮; 而第二種解決辦法就是看有沒有辦法生多個IP, 或是找proxy server的免費或付費服務。 基本上要多個IP就是得花錢多辦網路, 而免費的proxy服務又不穩定且常常失效, 付費的proxy也不確定是不是能符合要求不踩雷...。

想了些方案後忽然想到, 現在市面上的雲端服務都有一定額度的免費用量, 應該可以有辦法在不花錢的情況下解決這問題吧!! 基本上先不考慮要錢的VM, 以Azure來說可以選的就是Azure App Service以及Azure Function了。

以下是Azure web app以及Azure function的免費層價位:

Azure App Service(免費層最多10個app): 


Azure Function:


以上述兩種服務來說, Azure App Service最多可以開10個代表我最多可以拿到10組IP, 而Azure Function沒有個數限制, 代表我可以拿到的IP數沒有限制, 用Azure App Service的話只要每天超過1小時CPU用量當天就會不給連了, 而Azure Function則是要小心不要超過一百萬次 * 資源取用量。

再來就是POC了, 下面我寫了簡單的proxy轉發程式, 然後一次部署了五台Azure Function的服務, 分別開在不同的地區:



再來開個服務同時建五個async task往這五個proxy server打, 在用這些資料生成各美股的掃雷報表, 下圖是其中一個Azure Function的資源使用量:


沒想到資源的使用量比我想的大得多, 畢竟每生成一個報表都要打十幾個request, 稍微來換算一下, 一個小時我的執行次數就有2360次, 資源用量則是94.7M, 假設我繼續這樣不眠不休全力運轉打下去, 一個月的總用量:

-----

執行次數: 2360 * 24 * 30 = 1699200次

資源用量: 94.7M * 24 * 30 / 1024 = 68.69 GB-s

再加上我一次開五台, 所以總共是:

執行次數: 1699200 * 5 = 8496000次

資源用量: 68.69 * 5 = 343.45 GB-s

-----

資源用量離40萬GB-s還差得遠, 可是執行次數已經超過免費額度了, 所以一個月的費用為:
 (8496000- 1000000免費額度) / 1000000 * 6.011 = 45.05 台幣。

可以看見, 因為執行的都是I/O bound的工作, 所以用不到什記憶體, 可是執行次數還是閃不掉的, 不過不要整天 + 開多個服務去打request的話, 要用到一百萬次執行其實也蠻難的。不過這做法最讚的是, 我如果分散流量打得更開, 我要有多少IP就有多少IP, 根本就是Unlimited IP Works了!!


至於呼叫次數太多的問題, 我目前是打算在開個Azure Function的服務, 不過我這次會把生成掃雷報表的後端程式直接放上去, 這樣執行次數應該可以變成1/10以下, 相對的資源用量則會上漲許多, 不過看了上面的計算結果, I/O bound的工作資源用量要爆應該很難, 試試看就知道了XD

2020年11月15日 星期日

[重大更新] MahoMangaDownloaderVer13.0 & Ver13.1更新

Ver13.1 更新內容:

  • 改善dmzj頁數卡住問題

檔案位址:
https://drive.google.com/file/d/1Rd9yasvxPCFF1HycGti2kF8NytAzqQ6F/view?usp=sharing

32位元版本:
https://drive.google.com/file/d/13p9yAbJO5M8F6PQNWHpmntFOz53jWrgf/view?usp=sharing

解壓密碼:zmcx16

-------- 我是分隔線 --------


上個月有某個使用者回報下載器在某網站會有閃退的問題, 當時因為我沒辦法reproduce那問題, 所以也只能先放置並請對方先拿其他網站擋著用, 結果昨天開始我這邊終於能重現一樣的問題了, 看了下event log crash的點在CefSharp的process上, 只要有用到該process下載個幾分鐘後他就會自己crash, 之後有去Cefsharp的github issue找原因, 通常這類問題出在Chromium上比較多(畢竟CefSharp只是用.NET包裝一層Chromium的framework),遇到這問題也只能等Chromium update修bug, 而這個閃退的問題在我update CefSharp到最新版後就沒有再發生了。

再來就是問題點了, 基本上下載器我一直避免去更新第三方套件, 因為之前更新後總會有幾個使用者回報更新後出問題, 然後大多數是環境問題, 所以我都盡量避免去更新套件, 不過現在這閃退的問題不處理也不行, 偏偏CefSharp剛好我用的下一版本開始改成VC++2013 -> VC++ 2015, 這變成只要更新完下載器大多數使用者都會開不起來, 得安裝VC++ 2015 可轉散發套件才行...。

因為下載器本身是可攜式軟體, 我也不想主動幫使用者安裝套件, 所以還是跟以前一樣只能請使用者自己安裝了, 另外為了避免一堆人線上更新完後程式開不起來跑來問, 所以我有多做一個VC++ 2015的檢查, 檢查沒裝會主動跳訊息通知, 請使用者在自行去Microsoft網站下載安裝。


重要事項再放大字重點說明:

"MahoMangaDownloaderVer13.0必須安裝VC++ 2015 可轉散發套件, 原本的VC++2013只適用在下載器Ver12.5之前的版本!"

VC++ 2015 可轉散發套件下載位置:
https://www.microsoft.com/zh-tw/download/details.aspx?id=48145


再來就是固定的推坑時間, 這次想介紹的是很喜歡的作者: 羽海野千花

代表作品是蜂蜜幸運草(已完結)以及三月的獅子(不定期連載中)

這兩部作品基本上風格很像, 羽海野千花我覺得最厲害的地方就是他的作品溫差非常大, 溫馨愉快跟黑暗沉重的落差非常大, 簡單來說就是非常重口味(精神上), 搞笑愉快的時候非常愉悅, 嚴肅劇情時則是看到快胃痛, 而且除了最主要的主角群們以外, 每個配角也都有屬於自己的故事, 讓人更能對各個角色投注感情, 另外在三月的獅子更是加入了不少社會上最難搞的兩大問題: 家庭 & 霸凌問題, 描寫的非常有真實感以及讓人有代入感, 另外還有最最最厲害的地方就是"青春", 這作者的作品有滿滿的青春味, 常常看著都覺得自己年輕了十歲以上XD 非常推薦這兩部作品!!

以下是蜂蜜幸運草以及三月的獅子的部分內容:

蜂蜜幸運草: 存在感薄弱的男主角竹本生日:







對未來迷茫的竹本, 畢業作品中途打分時忽然來個神救援:




這個青春之塔後面還有各種小故事, 就先不捏他了XD

三月的獅子 - 第一話開頭:





------------------







被領養之後,沒想到卻讓對方家庭關係破裂...






男主角離開之後, 在某個機緣下被川本一家撿到(?)





將棋的世界







這是很嚴肅的將棋漫畫!!











這次介紹就到這裡, 蜂蜜幸運草除了原作漫畫以外, 還有動畫跟電影還有電視劇, 當初電視劇還是日劇台劇兩邊各自拍一部! 三月的獅子也有動畫, 不論是從漫畫還是動畫入坑都很推薦!!


Ver13.0 更新內容:

* 更新CefSharp套件 (63.0.1 -> 85.3.130)


下載器Demo圖:




介紹:

https://project.zmcx16.moe/?page=mahomangadownloader


MahoMangaDownloader下載器主要為幫助使用者改善線上漫畫的閱覽體驗, 如果試看的漫畫您非常喜歡, 也請麻煩購買正版支持原作者, 讓作家們能繼續創造出下一部更棒的作品。


環境需求

.Net framework 4.5.2或以上的版本

Visual C++ 2015 (只能安裝2015版, 其他版本不行)


簡單除錯:

* 如果下載失敗, 麻煩先用瀏覽器測試看資源是否存活。

* 如果能正常用瀏覽器瀏覽, 麻煩先查看LogFiles資料夾內的log檔案看錯誤訊息為何。

* 回報問題時, 麻煩提供有問題的網址以及log內容, 這樣我才有辦法測試找問題原因。


檔案位址:

https://drive.google.com/file/d/1fgZNxWlC86Uj7Hi_ouKgPgXGmhYBFufT/view?usp=sharing


32位元版本:

https://drive.google.com/file/d/1J6DAaVAUVhZcMvve4AplkFlIOyAuYMLe/view?usp=sharing


解壓密碼:zmcx16


免責聲明:

******************

MahoMangaDownloader僅作為學術研究使用,禁止利用本程式行非法用途。