有人可能會說，在本文中，我們將嘗試進行逆向工程。我們將把我們的髒手藏在每台網路伺服器的引擎蓋下，以任何人都不會利用的方式利用它們。
這個測試是在真空中對球形馬的測量，只不過是獲得了數據，現在我們不知道如何處理它。
技術
Nginx 和 Apache 的作業系統是 Ubuntu 18.04 LTS，適用於 IIS Windows Server Core 2019。在測試之前，所有作業系統都收到了截至 04.12.2019 年 XNUMX 月 XNUMX 日的最新更新。
測試僅透過 HTTP 進行。每個 Web 伺服器都運行相同的頁面，即 Codrops 提供的免費 Jekyll 模板。 。每個 Web 伺服器都禁用了 gzip 壓縮。
吞吐量測試是使用 Httpd-tools 完成的，參數如下：
ab -n 50000 -c 500 http://192.168.76.204:80/伺服器在 10、5 和 1 個核心上被限制為 8%、4% 和 9900% 的核心。測試台是一台 5400K@10MHz 的計算機，這意味著接收 540% 限制的伺服器每個核心接收約 XNUMXMHz。
TTFB測試是在伺服器首次啟動時進行的，並使用DevTools進行測量；收到結果後，關閉伺服器並回滾到先前的檢查點，以消除任何類型快取的出現。
測試器和 Web 伺服器位於同一主機和同一虛擬交換器上。
若要立即評估磁碟子系統、ATTO 和 CrystalDIskMark 基準測試的結果，以便了解瓶頸。
從虛擬機器取得的資料：
結果：
TTFB：
IIS 的平均 TTFB 最小，為 0,5 毫秒，而 Apache 為 1,4 毫秒，Nginx 為 4 毫秒。
吞吐量：
首先，讓我們看看每台伺服器根據核心數量進行擴充的效果如何。
此圖顯示了測試人員對 Web 伺服器的呼叫次數和延遲。該圖顯示 NGINX 處理了 98% 的請求，在 20 毫秒或更短的時間內交付了站點。 IIS 與 Apache 一樣，分別在 5 毫秒和 76 毫秒內完成了最後 14% 的呼叫。
此圖顯示了壓力測試期間一個請求的平均處理時間。
從圖中可以看出，IIS 擊敗了 Apache 和 Nginx，在高負載下速度顯著減慢。
IIS 顯然更喜歡 4 核而不是 XNUMX 核，顯示 XNUMX 核的延遲較低，但也不太喜歡 XNUMX 核。
NGINX 在所有 8 個核心上都能很好地擴展，對於 Apache 來說，單核場景似乎是最佳選擇。
可擴充性：
Nginx的：
現在讓我們看看頻率和核心數量的可擴展性。
Nginx 沒有通過 1 核和 4 核 1% 限制的測試；當超過 2000 個請求時，它終止了與測試器的連接。
阿帕奇：
Apache 和 Nginx 一樣，在處理了 2500 個請求後，放棄並關閉了連線。 Apache 在 8、4 和 1 核限制為 1% 的測試中都失敗了，但除此之外，它還在 5 核限制 XNUMX% 的測試中失敗了，這比 Nginx 還差
IIS：
在測試期間，IIS 累積了一個龐大的請求佇列，但處理了每個請求。顯然，開箱即用的請求處理沒有逾時設定。
此圖表顯示了完成測試所需的時間。完全荒謬的測試配置被丟棄。從圖中可以看出IIS對硬體的要求有多高，以及NGINX有多麼的出色。
從磁碟的可擴充性：
Nginx的：
現在讓我們看看頻率、核心數量以及磁碟速度的可擴展性。
這次 Nginx 失敗了 4 次測試，而不是兩次。
阿帕奇：
Apache 未通過的測試數量與上次相同。
IIS：
IIS 顯示幾乎相同的圖表，就好像沒有磁碟限制一樣。總的來說，所有伺服器的圖形都沒有太大變化，這意味著每個伺服器都將靜態資料快取在 RAM 中並從那裡提供服務。在這裡我們看到了主要的瓶頸——網頁伺服器本身。
根據此測試得出結論還為時過早；我們尚未使用 Let’s Encrypt 的即時憑證測試 HTTPS、壓縮和 HTTP/2。我們將在下一篇文章中討論這個問題。
來源： www.habr.com