Learn Traefik - Performance Tuning

#Introduction

A running Traefik is not necessarily an optimal Traefik. Episode 27 covers performance tuning: how Traefik uses resources, the parameters that most affect latency and throughput, and how to measure whether a change actually helps — not just feel that it does.

The main principle: do not optimize without measuring. We start with the transport connection, move into TLS, then discuss middlewares, and close with honest benchmarking. After this episode, you can get the most out of Traefik for your own workloads.

#Resource Optimization

#Memory and CPU

Traefik is lightweight, but memory usage is affected by a few things:

• Buffering middleware: holds payloads in memory — reduce memRequestBodyBytes if memory is limited.
• Access log buffering: a large bufferingSize adds to the memory footprint.
• Active connections: each connection uses a small amount of memory; accumulating idle connections adds load.

Allocate CPU to Traefik proportionally: dual-core is comfortable for hundreds of requests per second with basic middlewares. Scale up when using many heavy middlewares or TLS with high traffic.

#Transport Configuration

#ServersTransport for Backends

Traefik's connections to backends are governed by ServersTransport. The following parameters have the most impact:

http:
  serversTransports:
    prod:
      maxIdleConnsPerHost: 100
      idleConnTimeout: "90s"
      responseHeaderTimeout: "30s"
      dialTimeout: "5s"
      insecureSkipVerify: false

• maxIdleConnsPerHost: the number of idle connections kept per backend. A high value reduces the cost of opening new connections — the biggest effect for burst traffic.
• idleConnTimeout: when an idle connection is considered stale and closed.
• responseHeaderTimeout: the wait time for response headers; a slow backend uses up this quota then the connection is closed.
• dialTimeout: the time limit for opening a new connection to the backend.

A ServersTransport is attached to a service by name:

http:
  services:
    api-svc:
      loadBalancer:
        servers:
          - url: "http://10.0.0.130:8080"
        serversTransport: prod

#TLS Performance

#Session Resumption and HTTP/2

The TLS handshake is the most expensive operation in a proxy — every handshake consumes cryptographic CPU. Tricks to speed it up:

• TLS session resumption: client and server remember the session, so the next handshake is shorter. Traefik supports it by default.
• HTTP/2 multiplexing: many requests run over one TCP connection, reducing handshakes and head-of-line blocking at the connection level. Active by default on HTTPS entrypoints.
• Certificate caching: certificates are cached in memory; make sure acme.json is rarely accessed from disk.

For very high TLS traffic, consider terminating TLS at the front load balancer and having Traefik receive internal traffic — a control vs. performance trade-off you must assess yourself.

#Middleware Optimization

#Installation Strategy

Middlewares can become a burden, so install them deliberately:

• Order: decision middlewares (auth, rate limit) reject requests earlier, saving the work of other middlewares.
• Compress: compression consumes CPU. Do not compress small responses (set minResponseBodyBytes) or already compressed files.
• Buffering: only if needed — buffering adds memory and latency.
• Caching: Traefik does not provide built-in response caching; for static assets, put a CDN or cache layer in front.

#Benchmarking

#Measuring Tools

Before and after every change, measure with consistent tools:

wrk -t4 -c200 -d30s http://localhost/api

ab -n 10000 -c 100 http://localhost/api

k6 run --vus 100 --duration 30s script.js

Three tools with different characteristics: wrk is very fast and lightweight, ab is classic and available everywhere, k6 is script-based and suits complex scenarios. The wrk command with 200 parallel connections over 30 seconds gives a throughput and latency baseline.

#Reading the Results

Watch three numbers: requests/sec (throughput), latency percentiles (p95, p99), and error rate. Compare the baseline with the post-tuning results — if p95 drops and throughput rises, your change worked. If nothing changes, you may be hitting a bottleneck elsewhere: the backend, the network, or CPU.

#Closing

Key takeaways:

• Optimization starts with measurement: without a baseline, there is no direction.
• maxIdleConnsPerHost is the transport parameter with the most impact.
• TLS session resumption and HTTP/2 reduce handshake costs.
• Install middlewares deliberately: decisions first, transformations last.
• wrk, ab, and k6 are the standard benchmarking tools.
• Compare p95 and throughput before-after to validate.

In episode 28 next we will cover security hardening — least privilege principles, securing the dashboard, API, and metrics endpoints, strong TLS configuration, container security with non-root and read-only filesystems, and secret management with Docker secrets and Kubernetes secrets.