1. 前言

使用新的工具時，總會想拿來跟舊的東西比較一下，尤其是效能。雖然新的工具不見得主打效能，但心裡還是會希望它的表現不要太差。

最近想使用 Pingora。Pingora 是 Cloudflare 以 Rust 開發的開源網路代理框架，可以用來建立 HTTP reverse proxy、負載平衡器等服務。它具備高效能、連線重用及 Rust 的記憶體安全優勢。另外，Pingora 是 Framework，不是可以直接安裝、透過設定檔就完成所有設定的 Web Server，這和一般架設 Web Server 的模式有一些不一樣。

這次我使用的是 Pingora 的 Reverse Proxy 功能，所以想找一個有名、也比較熟悉的 Reverse Proxy 來比較。Nginx 就是我選定的對手。它不只是高效能的 Web Server，也是我以前經常拿來做 Reverse Proxy 的工具。

2. 測試環境

測試環境很簡單：

執行測試工具的主機: Nobara Linux

• 執行 oha 工具

被測試的主機: Alpine Linux (Diskless)

• 分開執行
  • Nginx
  • Pingora 執行檔
• musl libc 執行環境

後端 App 主機:

• k0s
  • 執行 Nginx 並顯示 Nginx welcome 頁面

3. 先測試 Proxy 本身的效能

一開始，我先測試 Pingora 和 Nginx 直接回應請求、不使用 upstream 的情況，想看看單純由 Proxy 處理請求時，兩者的效能差異。

使用 curl 先看一下 Nginx 和 Pingora 的 Response

curl http://192.168.1.151/test -v

Nginx test response:

*   Trying 192.168.1.151:80...
* Established connection to 192.168.1.151 (192.168.1.151 port 80) from 192.168.1.67 port 40002
* using HTTP/1.x
> GET /test HTTP/1.1
> Host: 192.168.1.151
> User-Agent: curl/8.18.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx
< Date: Sat, 24 Oct 2026 01:18:43 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 14
< Connection: keep-alive
<
Hello, world!
* Connection #0 to host 192.168.1.151:80 left intact

Pingora test response:

*   Trying 192.168.1.151:80...
* Established connection to 192.168.1.151 (192.168.1.151 port 80) from 192.168.1.67 port 46714
* using HTTP/1.x
> GET /test HTTP/1.1
> Host: 192.168.1.151
> User-Agent: curl/8.18.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
< Content-Length: 14
< Server: Pingora
< Date: Sat, 24 Oct 2026 01:25:05 GMT
< Connection: keep-alive
<
Hello, world!
* Connection #0 to host 192.168.1.151:80 left intact

測試使用指令:

oha -n 100000 -c 100 http://192.168.1.151/test

結果

原本對這個測試還有點期待，實際跑完後結果讓我滿失望的。

總結一下我這個時候做的設定:

Nginx:

• 預設的 process 數量設定 4 (worker_processes auto; // 依照主機 CPU core 數量)
• 關閉 access_log / error_log

Pingora:

• 程式碼內完全沒有任何設定

由於 Pingora 完全沒做任何設定，所以我嘗試做一些設定，我覺得 Pingora 和 Nginx 比起來效能不應該差這麼多。

嘗試了許久我做了以下這些設定改善了效能：(這些設定任何單一個都無法提升很多效能，但全部設定上去效能就上去了)

• conf.threads = 4;
  

• 將 Rust 預設的記憶體分配器替換為 jemalloc，測試後可以確實提高效能。

  • #[global_allocator]
    static GLOBAL: tikv_jemallocator::Jemalloc = tikv_jemallocator::Jemalloc;
    

將 Pingora 設定後的測試結果和 Nginx 的結果做比較

雖然結果仍然和 Nginx 還有一些差距，但我覺得已經足夠了，也覺得選擇使用 Pingora 滿有潛力的，可以繼續使用。

4. 加入 Upstream 後的測試

我把 upstream 加進設定，讓 Pingora 和 Nginx 都轉發請求到同一個跑在 k0s 裡的 Nginx (welcome page)。

Nginx 新增 upstream 設定:

• 使用 upstream block 並加入 keepalive 設定能避免 Nginx 在壓力測試的情境中出現大量的 connection TIME_WAIT 影響測試結果

  • upstream backend {
        server 192.168.1.150:30081;
        keepalive 100;
        keepalive_requests 1000;
        keepalive_timeout 60s;
    }
    

• Pingora 新增設定:

  • conf.upstream_keepalive_pool_size = 1000
    

測試命令：

oha -n 100000 -c 100 http://192.168.1.151/

加入實際的後端轉發後，Nginx 的吞吐量（Requests/sec）依然領先，但 Pingora 的測試結果，我覺得還不錯。

5. 結論

這次測試僅是我想要使用 Pingora，但不知道他的效能如何，想要安心使用所做的簡單測試與調教。

這篇只有看壓力測試工具測試的結果，但這個結果對我來說就夠了，如果是比較正式的測試，應該還要看更多的數據，比如 CPU 使用率、記憶體使用狀況等等。

這次測試讓我發現，Pingora 作為 Rust 開發的反向代理框架，並不代表在預設設定下就能取得比 Nginx 更高的吞吐量。在本次測試環境中，Nginx 在直接回應與簡單反向代理情境下，都展現了很好的效能。

另一方面，Pingora 經過執行緒、upstream 連線池及記憶體分配器等設定調整後，直接回應測試的吞吐量從約 5.2 萬 req/s 提升至約 17.1 萬 req/s，顯示設定與執行環境對效能有相當大的影響。

因此，若需求只是提供簡單的 HTTP 反向代理，Nginx 仍然是成熟且高效的選擇；若未來需要更高度客製化的代理流程，或希望與 Rust 生態系整合，Pingora 則值得進一步研究。