我們討論了方法論 在這篇文章中，我們在更現實的場景中測試 HTTPS。為了進行測試，獲得了 Let’s Encrypt 證書，並在 11 啟用了 Brotli 壓縮。
這次我們將嘗試重現 VDS 上部署伺服器或在具有標準處理器的主機上作為虛擬機器部署伺服器的場景。為此，設定了一個限制：
- 25% - 相當於 ~ 1350 MHz 的頻率
- 35%-1890MHz
- 41% - 2214 兆赫
- 65% - 3510 兆赫
一次性連線數從500個減少到1、3、5、7、9個，
結果：
延誤：
TTFB 被專門作為單獨的測試包含在內，因為 HTTPD 工具會為每個單獨的請求建立一個新使用者。這個測試仍然脫離現實，因為用戶仍然會點擊幾個頁面，而實際上 TTFP 將扮演主要角色。
第一個（通常是 IIS 虛擬機器首次啟動後的第一個請求）平均需要 120 毫秒。
所有後續請求均顯示 TTFP 為 1.5 毫秒。 Apache 和 Nginx 在這方面落後。就我個人而言，作者認為這個測試最具啟發性，並且只會根據它來選擇獲勝者。
結果並不奇怪，因為 IIS 快取已經壓縮的靜態內容，並且不會在每次存取時對其進行壓縮。
每個客戶花費的時間
要評估效能，使用 1 個連接進行測試就足夠了。
例如，IIS在5000秒內完成了40個使用者的測試，即每秒123個請求。
下圖顯示了網站內容完全傳輸所需的時間。這是在給定時間內完成的請求的比例。在我們的案例中，80% 的請求在IIS 上的處理時間為8 毫秒，在Apache 和Nginx 上的處理時間為4.5 毫秒，而Apache 和Nginx 上的所有請求中有8% 在最多98 毫秒的時間間隔內完成。
處理 5000 個請求的時間：
處理 5000 個請求的時間：
如果您的虛擬機器具有 3.5GHz CPU 和 8 核，請選擇您想要的。在此測試中，所有 Web 伺服器都非常相似。我們將在下面討論為每個主機選擇哪個 Web 伺服器。
當涉及到稍微更現實的情況時，所有網頁伺服器都會正面交鋒。
吞吐量：
延遲與同時連線數的關係圖。越平滑、越低越好。最後 2% 已從圖表中刪除，因為它們會使圖表難以閱讀。
現在讓我們考慮將伺服器託管在虛擬主機上的選項。我們以 4 GHz 的 2.2 個核心和 1.8 GHz 的 XNUMX 個核心為例。
如何擴展
如果您曾經看過真空三極管、五極管等的電流-電壓特性，那麼您會對這些圖感到熟悉。這就是我們想要抓住的——飽和度。限制是無論你投入多少個核心，效能的提升都不會很明顯。
以前，整個挑戰是以所有請求的最低延遲處理 98% 的請求，並儘可能保持曲線平坦。現在，透過建立另一條曲線，我們將找到每個伺服器的最佳工作點。
為此，我們採用每秒請求數 (RPR) 指標。水平是頻率，垂直是每秒處理的請求數，行數是核心數。
顯示 Nginx 處理一個又一個請求的效果的相關性。 8核心在本次測試中表現較好。
這張圖清楚地顯示了 Nginx 在單核心上的工作效果有多好（不是很多）。如果您有 Nginx，並且僅託管靜態內核，則應考慮將內核數量減少到 1。
儘管根據 Chrome 中的 DevTools 的數據，IIS 的 TTFB 最低，但在與 Apache 基金會的壓力測試的激烈競爭中，IIS 輸給了 Nginx 和 Apache。
圖表的所有曲率都被鐵定再現。
某種結論：
是的，Apache 在 1 核和 8 核上表現較差，但在 4 核上表現稍好一些。
是的，8 核上的 Nginx 在 1 核和 4 核上處理一個接一個的請求效果更好，但當有很多連接時，效果會更差。
是的，對於多執行緒工作負載，IIS 偏好 4 個核心，對於單執行緒工作負載，IIS 更喜歡 8 個核心。最終，儘管所有伺服器都處於同等水平，但在高負載下，IIS 在 8 核心上的速度比其他伺服器稍快。
這不是測量誤差，這裡的誤差不超過+-1ms。延遲且 RPR 每秒不超過 +- 2-3 個請求。
8 個核心性能較差的結果一點也不奇怪，如果我們有一個必須完成整個管道的時間範圍，許多核心和 SMT/超線程會大大降低效能。
來源： www.habr.com