千萬不要被網上的言論帶歪了，辟謠：
單純憑經驗斷定一個 PHP-FPM workers 程序占用多少記憶體是沒用的，單個 worker 程序的最高記憶體占用至少是「在 max_requests 内，記憶體占用最高的那次 request 所申請的記憶體」。
啟動大量的 PHP-FPM workers 程序并不能提升高并發的承載能力，反而會導緻大量 CPU 上下文切換，尤其是如果你的業務偏向于計算、單次請求所消耗的時間很長，增加 PHP-FPM 程序數量反而會導緻平均請求處理時長飙升。
Swoole / 容器 / Kubernetes 之類的東西并不是銀彈，你需要深入學習才能了解它(們)适不适合你的場景和需求。如果你沒有投入大量精力改造的準備，我不建議你考慮這些方案。并且，使用所謂的「容器」的确能夠将單個容器的 CPU 和記憶體壓到很低，但容器還是要運作在實際的實體機器上的，這對提升并發量并沒有什麼幫助，反而将一部分計算資源劃分給了容器排程程序。
我的建議是：
在新業務上線前，要得出你需要多大機器，你需要：(QPS*ART)/NOW=1。
QPS = Queries per Second. 每秒請求數量，也就是所謂的「并發量」。
ART = Average Response Time. 平均響應時間，機關秒。
NOW = Number of Workers. PHP-FPM Worker 的數量。
根據機關推算，這個公式可以寫為 (N/s*s)/N = 1，是以成立。
假設 QPS = 1000，ART = 0.1s，那麼 NOW 為 100 才能夠在理想狀态下，剛好滿足你的業務需求(也就是所有請求都可以在不排隊的情況下完成處理)。
那麼為了推算 NOW，你就需要知道 ART。你可以在一台 1 核心 CPU 的機器上跑一下你的業務，PHP-FPM max_children 保持為 1 即可。随後用壓測工具跑單并發，即可計算大概的平均響應時間。務必單線程，否則沒有參考價值。
得到 NOW，也就是所需的 Worker 數量之後，你就可以開始推算需要多大機器了。
一般來說，Worker 程序不建議超過 CPU 核心數的 2～4 倍。是以你可以使用 NOW / 2 甚至 NOW / 4 得到你所需要的 CPU 核心數。
至于記憶體，你同樣可以在一台記憶體足夠的機器上跑一跑你的業務，max_children 調大些，通過 systemctl 之類的工具觀察 FPM Worker 程序的記憶體占用，得出一個大概記憶體占用量的大概數值，随後将平均記憶體占用量 * NOW 即可。
最後，在生産環境中，建議你：
先按照推算數量向上提高一個檔位，部署一台機器。
随後通過 htop 等工具觀察實際的 CPU 和記憶體使用率，尤其是 Load Average 的值。
如果比較穩定或者偏低，可以再降低一個檔位部署一台機器(先不要銷毀老機器)。
随後在業務低峰将 DNS 記錄指向新機器，注意 DNS 記錄的 TTL 不要太高。
觀察新機器的 Load Average，如果偏高或者雪崩可以立即将 DNS Record 復原到老機器，恭喜你找到了适合你的機型。如果仍然偏低，可以繼續循環第 3 - 5 步，最終實踐出最适合你的 Instance Type。