當業務場景需要低延遲時，你會怎麼選擇？

這是最近和朋友討論的事，想研究的需求很簡單：

  1. 每次 (或 95%) 請求回應不得低於 30ms。
  2. 是否能夠壓在 30 台機器 / 實例內，承載每秒 5000 次請求。
  3. RESTful API 服務。
  4. 暫時不考慮資料庫連線，僅測試到 Routing 並馬上 Response。
  5. 最好還能 Leverage 現已採行的技術資源。

很多人可以從上述需求得知【業務場景】，因為 30ms 是關鍵訊息。至於為何想壓在 30 台機器內，除了機器硬成本因素外，還有架構部署、配置、管理的人力軟成本問題。就我的經驗上，超過 30 台機器後，很多問題會開發浮現，維運成本也會增加。

朋友目前使用 Ruby on Rails / Ruby，我使用 Phalcon Micro / PHP。都希望架構轉換不需要花太多成本，包括人員重新訓練、程式重構或重寫，若不得已最後才會考慮換另個程式語言全部重新撰寫。

於是，他從 Ruby Ecosystem 著力，嘗試 Ruby on Rails 及 Sinatra。我則是直接依 MUZIK Online 的經驗，從 Phalcon 及 Phalcon Micro，甚至搬出下一代的新架構 (估且稱為 New MUZIK)。以及兩個人同意的轉換王牌，Golang。

雙方把環境以 Docker 配置好，並以我的筆記型電腦為例進行效能測試。以下是符合【1. 每次 (或 95%) 請求回應不得低於 30ms】要求的數據。

  1. Nginx / Unicorn / Rails：每秒可處理 6 個請求。
  2. Nginx / Unicorn / Sinatra：每秒可處理 20 個請求。
  3. Nginx / PHP-fpm / Phalcon Micro：每秒可處理 40 個請求。
  4. New MUZIK：每秒可處理 180 個請求。
  5. Golang：每秒可處理 180 個請求。

若以 30 台機器，推估如下。 1. Nginx / Unicorn / Rails：每秒可處理 180 個請求。 2. Nginx / Unicorn / Sinatra：每秒可處理 600 個請求。 3. Nginx / PHP-fpm / Phalcon Micro：每秒可處理 1200 個請求。 4. New MUZIK：每秒可處理 5400 個請求。 5. Golang：每秒可處理 5400 個請求。

所以符合【2. 是否能夠壓在 30 台機器 / 實例下，承載每秒 5000 次請求】的只剩下 New MUZIK 及 Golang。

若還要符合【5. 最好還能 Leverage 現已採行的技術資源】則剩下 New MUZIK。因為 New MUZIK 完全可使用 PHP 開發及擴充的架構，我不需要讓所有人轉去學習非 PHP 程式語言。當然依據 New MUZIK 的使用經驗，Ruby 也是有機會可以做到這個地步，畢竟 New MUZIK 也是 leverage 別人在 PHP 上的開發成果。

另外，New MUZIK 在測試更高的每秒上千請求量時，目前表現與 Golang 差不多，這點讓我覺得頗開心。但這只是【4. 暫時不考慮資料庫連線，僅測試到 Routing 及馬上 Response】的數據，所以若在實際完整環境上，轉用 Golang 效果理應會更好。

最後，本篇為上述幾個需求場景中所進行的測試，並非適用於所有場景。