Caddy 與 Nginx的基準效能比較 - tjll

設計
我們今天只測試Caddy和Nginx，但我將沿著許多不同的軸線進行切割，以儘可能準確地瞭解它們各自的效能概況。

我將進行的測試將集中在三個方面。

• 純粹的代理內 "合成 "響應。我稱它們為 "合成"，因為代理只在自己的配置中形成響應程式碼和主體：在處理響應時，它不從磁碟檢索任何資產，也不與後端監聽服務交談。這就把響應請求的所有責任隔離給了反向代理本身，而沒有其他依賴資源。
• 提供檔案。反向代理一直在提供預編譯的靜態資產，所以這是一個重要的用例來衡量。它沒有合成測試那麼純粹，因為我們現在涉及到磁碟I/O，但請記住，反向代理也可以依靠快取。
• 反向代理。這是一個反向代理的麵包和黃油（希望這是顯而易見的）：與一個服務的後端監聽服務聊天。雖然這對測量來說超級重要，但做起來卻很棘手，因為現在你引入了一個完全獨立的過程，可能會影響響應時間。在實踐中，你的後端幾乎總是你的瓶頸，因為反向代理的工作只是傳遞流量。在這方面，我不太喜歡這個測試，因為後端目標的效能最終會滲入到資料中，但我們還是需要這樣做（因為 "開啟一個新套接字 "的測試路徑需要發生）。希望在其他條件相同的情況下，即使絕對值沒有嚴格的代表性，不同的測試執行之間的差異仍將是顯著的。

最後總結
我們學到了什麼？

• 對我來說，最引人注目的新知識是關於失敗模式的學習。Nginx會透過拒絕或放棄連線而失敗，Caddy會透過減慢一切速度而失敗。一個比另一個好嗎？對於某些使用情況，幾乎是肯定的。有些人想要快速失敗，而另一些人則希望不惜一切代價接受連線。關鍵的一點是，兩者是有區別的（坦率地說，我認為我更傾向於故障快速）。
• 正如預測的那樣，"synthetic"響應似乎是最容易的，其次是小的HTML檔案內容，其次是反向代理請求，其次是大的HTML內容。Nginx的快取行為讓它在處理靜態資產檔案時大放異彩（估計還有它的sendfile功能）。
• Caddy為Go語言的垃圾收集支付了費用，但這並不是一個壓迫性的費用（至少在 "正常 "流量水平下）。Nginx幾乎毫不費力地使用了大量的記憶體。Caddy在非破壞性測試中分配的真實記憶體達到了峰值，這可能是也可能不是很重要，這取決於作業系統可用的總記憶體量是多少。還有待觀察是什麼具體的程式碼路徑導致了所有這些malloc/free，但我的測試似乎指向了支撐reverse_proxy的任何機制。
• Caddy的預設配置是好的。我們把所有的核心都解鎖了，我們把所有可以使用的資源都啟動了，沒有任何記憶體洩漏。回顧一下，我的 "預設 "和 "最佳化 "Caddy配置是相同的。預設情況下，Nginx的範圍是單一核心（你可以從文件中瞭解到這一點，但我們現在已經直接針對Caddy觀察到這一點）。

對於 "Caddy或Nginx更好"，是否有一個答案？
也許沒有，但在這些知識的武裝下，也許你可以做出更明智的決定：
在選擇反向代理時，除了效能之外，還有其他因素需要考慮。你是否想要Caddy所包含的那些花哨的東西，比如對Let's Encrypt的第一部分支援和一個本地API？你想把你的Nginx知識直接帶到支援良好的k8s Nginx ingress控制器上嗎？從效能、安全或分析的角度來看，C語言與golang的執行時間對你來說是否重要？

我希望這是個有幫助的練習，併為未來的運營工程師提供有用的資料。