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

banq發表於2022-09-17
Nginx

這篇博文是關於將 Caddy 與 Nginx 及其各自的效能指標作為反向代理進行基準測試的。

出於某種原因，在我的職業生涯中，我花了過多的時間來處理反向代理。Apache、Nginx、traefik、各種kubernetes服務，以及最近的Caddy。我認為說Caddy一直是我的最愛，這並不是一種偶然的偏見：簡單、現代、快速，它做了一個現代反向代理應該做的事情，沒有太多的麻煩。

然而，有些人（可以理解！）在面對目前的衛冕冠軍Nginx和相對較新的Caddy之間的選擇時猶豫不決。Nginx已經存在了很長時間，在它所做的事情上非常出色。Caddy是新來的，它做了一些取捨，不管是好是壞--C語言和Golang語言只是一個例子，必然會導致某種效能上的差異。

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

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

 

相關文章