館長的網站技術瓶頸，小弟弟來解答 - 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.0IIS 10 + Windows (廢話）SQL Server (推測）OP Service: PleskWinHost: Google CloudDNS: 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 元，如果再不行就 ...