館長的網站技術瓶頸，小弟弟來解答 - notorious-2019.com 昨天看到館長的網站倒了，也看到館長說一個月花費大概一百萬左右的月費在支持這個架設的電商網站，也對外發布出來訊息，希望求救， 直接講結論 建議解法， 1. 首先要做的事情是讓整個網站可以橫向擴展 (Load Balancer + n 台伺服器），對，相信我，IIS 也是可以做 Scale out, 這是對於 Application layer 服務的解法。 2. 資料的部分 SQL 吞吐量，建議改成 GCP Cloud SQL, 或者就直接轉到 Azure SQL Server 環境上會相對容易解決 SQL 的問題。 上述 2 個步驟都處理完，其實 100 萬的費用，應該 20000 concurrent user 是沒有問題的，但前提是要設定『對』！ 額外需要花較長期時間要處理的，建議就是在 Queue 的處理，購物車的狀態都可以進入到 Queue 再來處理 SQL insert 的問題，減少不斷的 insert / update 的狀態，後文會提到 ... 底下詳細的會再說明如何後後續還有哪些處理的細節。 這兩天剛好有個小空擋，就來分析一下狀況， 可以從外部讀取得到的服務大致上如下， ASP.Net : 4.0 IIS 10 + Windows (廢話） SQL Server (推測） OP Service: PleskWin Host: Google Cloud DNS: Cloudflare 前端服務內容架構 Server-side render, jQuery base, 推測有可能採用現成購物車來進行，看起來不太像是用 wooCommerce 比較像是 Cart Functionality 這類的項目直接搭建而成（當然這純屬猜測） 功能拆解 因為網站是透過 Server site render 所有頁面都需要重新透過伺服器進行載入，這樣的狀況，如果在頻繁忙碌的 eCommerce 網站架構下會是一個致命傷， 簡單來說，數量的查詢，特惠價，優惠碼等等資訊的處理，使用者每做一步都需要重新跳轉頁面，或者整頁面重新讀取，只是為了部分的資料更新，這些都可以抽取出來成為 API ，透過 AJAX 的方式進行讀取。 讀寫分離 在不了解目前資料庫複雜狀態下，首先要讓所有人都
LINE Developer Day 2019 有一場 Session 讓自己一定要參加一下，LINE Ads platform revolution。 https://speakerdeck.com/line_devday2019/how-line-ads-platform-is-constantly-evolving Ads Platform 對於大部分的人來說，這可能是一個最熟悉的陌生人，對於電商平台以及眾多需要曝光的使用者來說， Ads 的來臨讓各位迎來曙光。 最直接的例子莫過於 Facebook 廣告投遞，簡單來說， 投標 -> 快曝光 (給錢) -> 轉換 -> 達到目標 但是，最重要的就是這個 BUT , 投標與曝光之間有許多事情需要進行。 數位廣告已經脫離一刊 100 元的年代許久（雖然許多公司還是用這樣的概念在做事情），但實際上的概念是， 投標 -> 達到標地 -> 投遞 -> 投遞總量 * 投標金額 / 目標轉換 當此數字出來時，才會是大家所期待看到 100 元 / Click (或者任何轉換) 的計算金額。 聰明的各位肯定有想到了，這樣最簡單的方式，其實並不是告訴大家要投標多少，而是從使用者希望的轉換的預期金額，來進行回推投標金額。 因此還是一樣的概念，投標數字越高，就可以越快達到標，簡單來說就是， 如果有 100 元達不到的事情，那就 200 元，如果再不行就 ... Ads Platform 驚奇之旅 對於廣告平台來說，有兩件事情， 讓使用者願意投錢 使用者投遞的錢，可以適當的放到正確位置，給正確的人 在所謂的 Realtime bidding 當中，最困難的部分莫過於， Realtime 的部分，以 LINE 的例子來說，如果台灣有 1900 萬的使用者，意味著如何在投遞的過程中做出 87% 相似，或盡量做到與實際狀況相同的推估，這要將 Data 在之前做大量的預先處理，以及對於版面的選擇做最優化處理，包含此群眾與版面之間互動關係推估等，會是 UI API DATA / Rules AI / Preprocess 這幾個項目的結合，才可能可以做到很適當的配合與推估行為，讓使用者投遞金額時達到一定的信心程度，同時使