(由於平台不支援 LaTex, 下面用日常寫法替代)
在開始之前, 我們需要先對一些指標 (或是數字) 有敏感度
希望閱讀在本文之後, 我們都能夠回答下面的問題
先認識一下常見的幾種時間單位縮寫
時間單位的長度從上至下每個差距為 10^3 倍, 所以
1 s = 10^3 ms = 10^6 μs = 10^9 ns
每差 n 個階層, 就是 n * 3 個 0, 比如 s 和 mus 差了兩個階層, 差距就是 10^6 倍 (6 個 0)
一樣只提幾個常見的單位
雖然嚴格來說, 資料單位的每個階層都差距 1024 倍 (2^10, 2 的倍數方便存取)
但其實只要記最大的單位就好, 比如實際上 1 MB = 1024 KB, 但方便起見可以捨去零頭, 記成 1 MB ~ 1000 KB 即可, 所以是
1 PB ~ 10^3 TB ~ 10^6 GB ~ 10^9 MB ~ 10^12 KB ~ 10^15 Bytes
雖然開頭提到的各種操作所需時間要視實際的硬體規格決定, 但我們仍然可以有個 "大概" 的概念, 比如
從上面列表可以得知, 網路和硬碟存取都是 "相對慢" 的操作 (ms 級), 所以 I/O 通常是 performance bottleneck
題外話
雖然大家都詬病 HDD 的讀寫速度, 確實 SSD 因為用 flash memory 取代了磁頭, 所以比 HDD 快了約 100 倍
但是看 "連續讀取" 的話, 其實只差了 20 倍
所以對於具有 Read-heavy 特性的資料來說, 或許可以用 HDD 就好
雖然 Query 有分讀跟寫, 但一般來說讀取的量級會大於寫 (即使是 OLTP 服務)
所以日常講的 QPS 多是指讀取
以 Google Search 為例, QPS 為 40,000
由於未註冊的人也可以使用 Google Search, 所以全球都是潛在用戶
且每個人每天平均都會搜尋 10 次以上, 才造成這麼高的 QPS
但是並不是所有公司都會公開自己的統計數據
那麼該如何估算 QPS 呢?
一般需註冊的服務來說, 我們可以從 DAU (Daily Active User) 推論
Instagram
以 Instagram 首頁來說, MAU (Monthly Active User) 為 2 billion, 約為 60 million DAU
假設每個用戶每天會打開首頁 10 次 (可能保守了@@), 在不考慮其背後優化請求的情況下 (ex. CDN, Frontend cache), 一天會有 60 million * 10 次 = 600 million (6 億) 次首頁的 query
所以是 6 * 10^8 quries/day, 又一天大約有 10^5 秒, 所以可以概估 Instagram 首頁每秒約有 6 * 10^8 / 10^5 = 6000 QPS
雖然相較於 Google Search 較少, 但 Instagram 的功能遠不止首頁的推薦, 這邊僅提供一個數字供參考
若我們想自己開發一個服務, 且 TA (Target Audience) 為台灣, 2024 年台灣人口總數約為 2 千萬, 即 2 * 10^7
假設所有台灣人都是潛在用戶, 且平均 DAU 為總用戶數的 10%, 那一天的請求數量約為 2 * 10^7 * 10% = 2 * 10^6 (2 百萬), 所以 QPS 為 2 * 10^6 / 10^5 = 20
有了這個概念後, 若未來某天你自己或聽到朋友開發的服務平均有幾百甚至幾千 QPS, 你就可以驚訝的說 "怎麼這麼高!" 了!
iThome鐵人賽
看影片追技術