I'm stress-testing a small service at roughly 1,000 requests per second through Cloudflared and Traefik running on k3s. The machine has 2 Oracle Cloud OCPUs and 12 GB of RAM. Together, the proxy and tunnel consume more than 80% of the CPU, while the Rust API and SQLite workload use only about 20%. The application performs database queries, parsing, JSON serialization, routing, batching, and some disk writes, yet it remains relatively lightweight.
This seems unexpectedly expensive for two components that mostly forward traffic. In an earlier setup, Caddy handled TLS and routing on weaker hardware while reaching more than 10,000 requests per second with lower and more stable resource usage. I've checked the behavior with htop, btop, and perf. Even around 100 workers causes CPU usage to spike above 90%, and perf shows a large amount of system-time usage in the proxy path. Is this expected for Cloudflared plus Traefik, or does it suggest a configuration, protocol, logging, connection, or tunneling issue?
3 Answers
Profile each hop separately before assuming the proxy itself is inefficient. Test the API directly, through Traefik without Cloudflared, and then through the full tunnel. Keep the request body and response identical and record latency, connection reuse, TLS settings, access logging, compression, retries, and HTTP version. A tunnel carrying short-lived connections can spend far more CPU per request than a local reverse proxy, especially if clients are not reusing connections.
At 1,000 requests per second on only two virtual CPUs, high usage from the tunnel and ingress proxy is not automatically abnormal. Cloudflared has to encrypt, encapsulate, and maintain tunnel connections, while Traefik still handles connection management, routing, and possibly TLS, HTTP, access logs, and Kubernetes processing. The important comparison is not just total CPU, but requests per second, request size, keep-alive behavior, latency, and whether the traffic is HTTP or something being carried as generic TCP.
The system-time result is worth investigating. Check for excessive connection creation, socket or conntrack pressure, packet fragmentation, MTU problems, retransmits, encryption overhead, and container networking between the host, k3s, Traefik, and the tunnel. Also verify that debug or access logging is not enabled and that you are comparing the same concurrency model. A direct Nginx or Caddy benchmark is useful, but it only becomes a fair comparison if the protocol, keep-alive settings, TLS termination, and traffic path are equivalent.
That makes sense as a baseline, but the same workload previously reached over 10,000 requests per second through Caddy with lower CPU usage. Perf also shows a surprisingly large amount of system time, so I’m trying to determine whether this is simply tunnel overhead or a misconfiguration.