Проксирование из коробки: сравнительный анализ HAProxy, Envoy, Nginx, Caddy и Traefik

Всем привет, меня зовут Стас, я техлид в Mish Product Lab.

Тема возникла не просто так: внутри команды у нас было немало споров и дискуссий о том, какой инструмент для проксирования и терминации SSL лучше использовать в различных ситуациях. Изначально все наши гипотезы были основаны больше на личных предпочтениях, чем на реальных данных. Мы долго спорили, надеясь, что истина будет где-то рядом с нашими любимыми решениями. Но в итоге пришли к выводу, что единственный способ получить действительно объективный ответ — это протестировать и сравнить различные варианты на практике.

Именно так родилась идея провести сравнительный анализ производительности HAProxy, Envoy, Nginx, Caddy и Traefik с поддержкой SSL/TLS. Мы хотели понять, какой из инструментов «из коробки» предоставляет наилучшую производительность и минимальные накладные расходы, особенно при обработке SSL-трафика, который, как известно, требует дополнительных ресурсов из-за шифрования и дешифрования.

Важно подчеркнуть, что наша задача не заключалась в поиске идеального или максимально оптимизированного решения. Для глубоких и тонких настроек всегда лучше обратиться к DevOps-инженерам, которые обладают необходимыми компетенциями и понимают нюансы каждого инструмента. Нашей целью было скорее провести «полевые испытания» и составить заметки, которые могли бы помочь нам самим и будущим поколениям разработчиков быстрее принимать решения на основе хотя бы приблизительных ориентиров.

Итак, мы готовы поделиться нашими наблюдениями и результатами тестов.

Работаем с тестовыми стендами

Для обеспечения объективности и прозрачности тестирования мы выбрали три отдельных стенда, каждый из которых отвечал за свою часть сценария нагрузки. Разделение ролей стендов было принципиально важным для минимизации возможных взаимных влияний и искажений результатов. Это позволило максимально точно зафиксировать поведение каждого инструмента и компонента инфраструктуры.

Все тестовые стенды были размещены в одной сети, что гарантировало стабильную и предсказуемую сеть без значительных задержек. Никаких настроек ядра, голые системы.

• Тестовый стенд 1 (K6) предназначался для генерации и управления трафиком при помощи инструмента K6. Его ресурсы (32 vCPU, 128 ГБ RAM) обеспечивали возможность генерировать существенную нагрузку и давала нам уверенность в том, что сам инструмент генерации не станет узким местом.

• Тестовый стенд 2 (Web) был основным объектом тестирования. Здесь были установлены различные инструменты для проксирования (HAProxy, Envoy, Nginx, Caddy, Traefik) и мониторинг штатными средствами хостера. Это позволило нам не только протестировать производительность каждого решения, но и подробно отслеживать потребление ресурсов. Ресурсы 32 vCPU, 128 ГБ RAM.

• Тестовый стенд 3 (Backend) выполнял роль типичного приложения (backend), написанного на Golang, которое должно было принимать и обрабатывать запросы, проходящие через прокси. Ресурсы 8 vCPU, 32 ГБ RAM.

Такое разделение ролей и ресурсов дало возможность получить максимально чистые и объективные данные о производительности каждого инструмента.

Работаем с бэкэндом

Сервис делали на Golang, для обработки запросов использовали fasthttp — никаких излишеств.

package main  import (         "fmt"         "log"          "github.com/valyala/fasthttp" )  func main() {         fmt.Println("Listening on :8080")         requestHandler := func(ctx *fasthttp.RequestCtx) {                 switch string(ctx.Path()) {                 case "/":                         handleRoot(ctx)                 default:                         ctx.Error("Unsupported path", fasthttp.StatusNotFound)                 }         }          if err := fasthttp.ListenAndServe(":8080", requestHandler); err != nil {                 log.Fatalf("Error in ListenAndServe: %s", err)         } }  func handleRoot(ctx *fasthttp.RequestCtx) {         ctx.SetStatusCode(fasthttp.StatusOK)         ctx.SetBodyString("hello world") } 

Запускаем стресс-тест на этот сервис: 50 000 rps, 1 минута

K6 (генерация трафика и проверка ответа, http code и body):

import http from 'k6/http'; import { check } from 'k6';  export let options = {   scenarios: {     constant_request_rate: {       executor: 'constant-arrival-rate',       rate: 50000,       timeUnit: '1s',       duration: '60s',       preAllocatedVUs: 1000,       maxVUs: 100000,     },   }, };  export default function () {   let res = http.get('http://10.0.0.8:8080');    check(res, {     'status is 200': (r) => r.status === 200,     'body contains expected content': (r) => typeof r.body === 'string' && r.body.includes('hello world'),   }); } 

scenarios: (100.00%) 1 scenario, 100000 max VUs, 1m30s max duration (incl. graceful stop):          * constant_request_rate: 50000.00 iterations/s for 1m0s (maxVUs: 1000-100000, gracefulStop: 30s)    █ THRESHOLDS       checks     ✓ 'rate>=0.95' rate=100.00%      http_req_duration     ✓ 'p(95)<500' p(95)=387.29µs      http_req_failed     ✓ 'rate<0.01' rate=0.00%    █ TOTAL RESULTS       checks_total.......................: 5993052 99880.644605/s     checks_succeeded...................: 100.00% 5993052 out of 5993052     checks_failed......................: 0.00%   0 out of 5993052      ✓ status is 200     ✓ body contains expected content      HTTP     http_req_duration.......................................................: avg=283.17µs min=110.92µs med=234.52µs max=235.41ms p(90)=324.36µs p(95)=387.29µs       { expected_response:true }............................................: avg=283.17µs min=110.92µs med=234.52µs max=235.41ms p(90)=324.36µs p(95)=387.29µs     http_req_failed.........................................................: 0.00%   0 out of 2996526     http_reqs...............................................................: 2996526 49940.322303/s      EXECUTION     dropped_iterations......................................................: 3476    57.931271/s     iteration_duration......................................................: avg=349.05µs min=142.88µs med=277.87µs max=1.06s    p(90)=374.7µs  p(95)=453.85µs     iterations..............................................................: 2996526 49940.322303/s     vus.....................................................................: 15      min=10           max=183      vus_max.................................................................: 1044    min=1044         max=1044      NETWORK     data_received...........................................................: 438 MB  7.3 MB/s     data_sent...............................................................: 246 MB  4.1 MB/s 

Результат — тест выполнен успешно.
Максимальная задержка — max=47.52ms

Пропускная способность — 49964.433616/s

Настройка и тестирование проксирования

K6 (генерация трафика и проверка ответа, http code и body):

import http from 'k6/http'; import { check } from 'k6';  export let options = {   scenarios: {     constant_request_rate: {       executor: 'constant-arrival-rate',       rate: 50000,               // количество запросов в секунду       timeUnit: '1s',            // единица времени для rate       duration: '60s',           // длительность теста       preAllocatedVUs: 1000,     // количество предварительно выделенных виртуальных пользователей       maxVUs: 100000,            // максимальное количество VU, которое может быть задействовано     },   },   thresholds: {     checks: ['rate>=0.95'],     http_req_failed: ['rate<0.01'],     http_req_duration: ['p(95)<500'],   }, };  export default function () {   let res = http.get('https://test-backend.mish.design');    check(res, {     'status is 200': (r) => r.status === 200,     'body contains expected content': (r) => typeof r.body === 'string' && r.body.includes('hello world'),   }); } 

Получаем сертификат:

sudo apt install certbot sudo certbot certonly --standalone -d test-backend.mish.design 

Сертификаты появятся тут:

/etc/letsencrypt/live/test-backend.mish.design/fullchain.pem /etc/letsencrypt/live/test-backend.mish.design/privkey.pem 

Теперь совместим их — это нужно для HAProxy:

cd /etc/letsencrypt/live/test-backend.mish.design/ cat fullchain.pem privkey.pem > haproxy.pem 

HAProxy

Начать решили именно с HAProxy, так как он позволяет максимально быстро и эффективно протестировать работоспособность архитектуры без сложной предварительной настройки инфраструктуры.

docker-compose.yml

• HAProxy запускается через Docker Compose, что позволяет легко воспроизводить окружение на разных серверах и машинах разработчиков.

• Порты 80 и 443 прокидываются наружу, то есть сервис явно ориентирован на обработку HTTP и HTTPS-запросов.

• SSL-сертификат Let’s Encrypt подключается напрямую через volume, таким образом сервис сразу готов к работе в защищённом режиме (HTTPS).

services:   haproxy:     image: haproxy:latest     container_name: haproxy     ports:       - "80:80"       - "443:443"     volumes:       - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro       - /etc/letsencrypt/live/test-backend.mish.design/haproxy.pem:/usr/local/etc/haproxy/certs/haproxy.pem:ro 

haproxy.cfg

HAProxy настроен в режиме http, и весь трафик, поступающий на порт 443, перенаправляется в backend-сервис, указанный в конфигурации (10.0.0.8:8080).

defaults     mode http  frontend main     bind *:443 ssl crt /usr/local/etc/haproxy/certs/haproxy.pem     default_backend test_backend  backend test_backend     server test_backend_server 10.0.0.8:8080 check 

Запускаем созданный выше сценарий

scenarios: (100.00%) 1 scenario, 100000 max VUs, 1m30s max duration (incl. graceful stop):          * constant_request_rate: 50000.00 iterations/s for 1m0s (maxVUs: 1000-100000, gracefulStop: 30s)    █ THRESHOLDS       checks     ✓ 'rate>=0.95' rate=100.00%      http_req_duration     ✓ 'p(95)<500' p(95)=1.16ms      http_req_failed     ✓ 'rate<0.01' rate=0.00%    █ TOTAL RESULTS       checks_total.......................: 5967620 99455.517508/s     checks_succeeded...................: 100.00% 5967620 out of 5967620     checks_failed......................: 0.00%   0 out of 5967620      ✓ status is 200     ✓ body contains expected content      HTTP     http_req_duration.......................................................: avg=759.38µs min=330.64µs med=571.94µs max=1.07s p(90)=861.18µs p(95)=1.16ms       { expected_response:true }............................................: avg=759.38µs min=330.64µs med=571.94µs max=1.07s p(90)=861.18µs p(95)=1.16ms     http_req_failed.........................................................: 0.00%   0 out of 2983810     http_reqs...............................................................: 2983810 49727.758754/s      EXECUTION     dropped_iterations......................................................: 16192   269.8536/s     iteration_duration......................................................: avg=984.55µs min=360.44µs med=643.34µs max=1.36s p(90)=968.37µs p(95)=1.35ms     iterations..............................................................: 2983810 49727.758754/s     vus.....................................................................: 34      min=28           max=357      vus_max.................................................................: 1293    min=1293         max=1293      NETWORK     data_received...........................................................: 374 MB  6.2 MB/s     data_sent...............................................................: 108 MB  1.8 MB/s 

Нагрузка на систему

Основные выводы:

CPU

• Загрузка до ~900% (9 ядер), стабильна весь тест → CPU справился.

K6 Test Summary

• RPS (успешные): 49,728 / сек

• Ошибки: 0% (http_req_failed = 0.00%)

• Дропнутые итерации: 16,192 (≈0.5%)

• Время ответа p(95): 1.16 ms

• Макс. задержка: 1.07s

• Объём данных:

  • Получено: 374 MB (6.2 MB/s)

  • Отправлено: 108 MB (1.8 MB/s)

• VUs использовано: 28–357

• Макс. допустимо: 1293 VUs

Отличная производительность, минимальные задержки, всё стабильно.

Envoy

Высокопроизводительный прокси-сервер и балансировщик нагрузки, разработанный компанией Lyft, поддерживающий динамическое конфигурирование, observability и множество современных протоколов.

docker-compose.yml

• Envoy разворачивается через Docker Compose для простоты повторяемости окружения.

• Порты 80 и 443 открываются для обработки входящего трафика.

• Используется сертификат Let’s Encrypt, напрямую подключённый в конфигурацию.

services:   envoy:     image: envoyproxy/envoy-dev:latest     container_name: envoy     environment:      - "ENVOY_UID=0"     volumes:      - /etc/letsencrypt:/etc/certs:ro      - ./envoy.yaml:/etc/envoy/envoy.yaml     ports:      - "80:80"      - "443:443" 

envoy.yaml

• Запросы, поступающие на домен test-backend.mish.design, перенаправляются на backend-сервис по адресу 10.0.0.4:8080 с балансировкой по алгоритму round-robin.

• Envoy автоматически терминирует TLS-соединения и маршрутизирует трафик по HTTP.

static_resources:   secrets:     - name: server_cert       tls_certificate:         certificate_chain:           filename: /etc/certs/live/test-backend.mish.design/fullchain.pem         private_key:           filename: /etc/certs/live/test-backend.mish.design/privkey.pem    listeners:   - name: back_listener     address:       socket_address:         address: 0.0.0.0         port_value: 443     filter_chains:     - filters:       - name: envoy.filters.network.http_connection_manager         typed_config:           "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager           codec_type: AUTO           stat_prefix: ingress_http           upgrade_configs:           - upgrade_type: websocket           route_config:             name: local_route             virtual_hosts:             - name: main               domains:               - "test-backend.mish.design"               routes:               - match:                   prefix: "/"                 route:                   cluster: back           http_filters:           - name: envoy.filters.http.router             typed_config:               "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router        transport_socket:         name: envoy.transport_sockets.tls         typed_config:           "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext           common_tls_context:             tls_certificate_sds_secret_configs:              - name: server_cert    clusters:   - name: back     connect_timeout: 5s     type: STRICT_DNS     lb_policy: ROUND_ROBIN     load_assignment:       cluster_name: back       endpoints:       - lb_endpoints:         - endpoint:             address:               socket_address:                 address: 10.0.0.4                 port_value: 8080  

Запускаем созданный выше сценарий

scenarios: (100.00%) 1 scenario, 100000 max VUs, 1m30s max duration (incl. graceful stop):          * constant_request_rate: 50000.00 iterations/s for 1m0s (maxVUs: 1000-100000, gracefulStop: 30s)    █ THRESHOLDS       checks     ✓ 'rate>=0.95' rate=100.00%      http_req_duration     ✓ 'p(95)<500' p(95)=3.34ms      http_req_failed     ✓ 'rate<0.01' rate=0.00%    █ TOTAL RESULTS       checks_total.......................: 5970208 99497.954679/s     checks_succeeded...................: 100.00% 5970208 out of 5970208     checks_failed......................: 0.00%   0 out of 5970208      ✓ status is 200     ✓ body contains expected content      HTTP     http_req_duration.......................................................: avg=1.38ms min=421.73µs med=1ms    max=131.98ms p(90)=2.11ms p(95)=3.34ms       { expected_response:true }............................................: avg=1.38ms min=421.73µs med=1ms    max=131.98ms p(90)=2.11ms p(95)=3.34ms     http_req_failed.........................................................: 0.00%   0 out of 2985104     http_reqs...............................................................: 2985104 49748.977339/s      EXECUTION     dropped_iterations......................................................: 14895   248.236248/s     iteration_duration......................................................: avg=1.63ms min=454.49µs med=1.08ms max=1.15s    p(90)=2.33ms p(95)=3.87ms     iterations..............................................................: 2985104 49748.977339/s     vus.....................................................................: 59      min=49           max=291      vus_max.................................................................: 1262    min=1246         max=1262      NETWORK     data_received...........................................................: 597 MB  9.9 MB/s     data_sent...............................................................: 344 MB  5.7 MB/s 

Нагрузка на систему

Основные выводы:

CPU

• Загрузка до ~1600% → использовано до 16 ядер, держалось стабильно.

K6 Test Summary

• RPS (успешные): 49,749 / сек

• Ошибки: 0%

• Дропнутые итерации: 14,895 (≈0.5%)

• Время ответа p(95): 3.34 ms

• Макс. задержка: 132 ms

• Объём данных:

  • Получено: 597 MB (9.9 MB/s)

  • Отправлено: 344 MB (5.7 MB/s)

• VUs использовано: 49–291

• Макс. допустимо: 1262 VUs

Отличная производительность, минимальные задержки, всё стабильно.

Traefik

Современный обратный прокси и балансировщик нагрузки с встроенной поддержкой автоматической выдачи и обновления SSL-сертификатов через Let’s Encrypt. Он разработан для динамической работы с контейнерными средами, такими как Docker и Kubernetes.

docker-compose.yml

• Запуск через Docker Compose — Traefik работает как отдельный сервис в контейнере.

• Порты 80 и 443 — открыт для приёма HTTP и HTTPS-трафика.

• Сертификаты Let’s Encrypt — полностью автоматическая выдача и хранение сертификатов.

services:   traefik:     image: traefik:latest     container_name: traefik     ports:       - "80:80"       - "443:443"     volumes:       - /var/run/docker.sock:/var/run/docker.sock       - ./traefik_data:/etc/traefik       - ./traefik_data/dynamic_conf.yml:/etc/traefik/dynamic_conf.yml     command:       - "--log.level=ERROR"       - "--accesslog=false"       - "--api.dashboard=false"       - "--providers.docker=true"       - "--providers.docker.exposedbydefault=false"       - "--providers.file.filename=/etc/traefik/dynamic_conf.yml"       - "--entrypoints.web.address=:80"       - "--entrypoints.websecure.address=:443"       - "--certificatesresolvers.myresolver.acme.httpchallenge=true"       - "--certificatesresolvers.myresolver.acme.httpchallenge.entrypoint=web"       - "--certificatesresolvers.myresolver.acme.email=example@yandex.com"       - "--certificatesresolvers.myresolver.acme.storage=/etc/traefik/acme.json" 

dynamic_conf.yml

• Запросы на test-backend.mish.design по HTTPS идут на backend-сервис по адресу http://10.0.0.8:8080.

• Используется entryPoint websecure (порт 443).

• Балансировка выполняется на уровне Traefik.

http:   routers:     myrouter:       rule: "Host(`test-backend.mish.design`)"       entryPoints:         - websecure       tls:         certResolver: myresolver       service: myservice    services:     myservice:       loadBalancer:         servers:           - url: "http://10.0.0.4:8080" 

Запускаем созданный выше сценарий

scenarios: (100.00%) 1 scenario, 100000 max VUs, 1m30s max duration (incl. graceful stop):          * constant_request_rate: 50000.00 iterations/s for 1m0s (maxVUs: 1000-100000, gracefulStop: 30s)    █ THRESHOLDS       checks     ✗ 'rate>=0.95' rate=67.15%      http_req_duration     ✗ 'p(95)<500' p(95)=8.46s      http_req_failed     ✗ 'rate<0.01' rate=32.84%    █ TOTAL RESULTS       checks_total.......................: 723606 9317.72162/s     checks_succeeded...................: 67.15% 485906 out of 723606     checks_failed......................: 32.84% 237700 out of 723606      ✗ status is 200       ↳  67% — ✓ 242953 / ✗ 118850     ✗ body contains expected content       ↳  67% — ✓ 242953 / ✗ 118850      HTTP     http_req_duration.......................................................: avg=2.11s min=0s       med=70.12ms  max=32.98s p(90)=6.25s  p(95)=8.46s        { expected_response:true }............................................: avg=2.47s min=622.32µs med=289.6ms  max=32.98s p(90)=6.68s  p(95)=9.22s      http_req_failed.........................................................: 32.84%  118850 out of 361803     http_reqs...............................................................: 361803  4658.86081/s      EXECUTION     dropped_iterations......................................................: 2088749 26896.379681/s     iteration_duration......................................................: avg=4.42s min=1.1ms    med=358.05ms max=1m0s   p(90)=10.28s p(95)=27.16s     iterations..............................................................: 361803  4658.86081/s     vus.....................................................................: 26      min=26               max=29182     vus_max.................................................................: 29243   min=2532             max=29243      NETWORK     data_received...........................................................: 126 MB  1.6 MB/s     data_sent...............................................................: 24 MB   308 kB/s 

Нагрузка на систему

Основные выводы:

CPU

• Загрузка до ~3000% → задействовано ~30 ядер.

Network Traffic

• Периоды падения, из-за ошибок и дропов.

K6 Test Summary (Traefik)

• Успешные запросы: 4,659 RPS (в 10 раз ниже цели)

• Ошибки: 32.84%

• Дропы: 2,088,749 итераций ( огромный уровень отказов)

• p(95) ответа: 8.46 сек

• Максимальная задержка: 32.98 сек (!)

• Передано:

  • Получено: 126 MB (1.6 MB/s)

  • Отправлено: 24 MB (308 KB/s)

• VUs: до 29,243 → рост числа VUs указывает на тяжёлую деградацию под нагрузкой

Вывод:

• Traefik не справился с 50k RPS.

• Наблюдаются:

  • Массовые дропы итераций

  • Высокие задержки

• Требуется оптимизация, либо он не подходит для такого уровня нагрузки в текущей конфигурации.

Nginx

Классический веб-сервер и обратный прокси, известный своей стабильностью, высокой производительностью и минимальным потреблением ресурсов. Один из самых популярных инструментов для терминации TLS, балансировки нагрузки и проксирования трафика

docker-compose.yml

• Запуск через Docker Compose — контейнер с NGINX разворачивается быстро и удобно.

• Открыты порты 80 (HTTP) и 443 (HTTPS) для обработки входящего трафика.

• Подключены сертификаты от Let’s Encrypt для обеспечения HTTPS.

services:   nginx:     image: nginx:latest     volumes:       - ./default.conf:/etc/nginx/nginx.conf       - /etc/letsencrypt/live/test-backend.mish.design/fullchain.pem:/etc/letsencrypt/live/test-backend.mish.design/fullchain.pem:ro       - /etc/letsencrypt/live/test-backend.mish.design/privkey.pem:/etc/letsencrypt/live/test-backend.mish.design/privkey.pem:ro     ports:       - "80:80"       - "443:443" 

default.conf

• Прописаны все основные заголовки для правильной передачи оригинального IP и схемы клиента на backend.

• worker_processes auto; — количество воркеров подстраивается под доступные ядра.

• worker_rlimit_nofile 100000; — увеличен лимит на количество открытых файлов (важно при высоких нагрузках).

• worker_connections 5000; и multi_accept on; — рассчитано на большое количество одновременных соединений.

• Используется epoll — эффективный режим для Linux-систем с высоким количеством соединений.

worker_processes auto; worker_rlimit_nofile 300000;  events {     worker_connections 5000;     multi_accept on;     use epoll; }  http {   server {     listen 443 ssl;     server_name test-backend.mish.design;      ssl_certificate /etc/letsencrypt/live/test-backend.mish.design/fullchain.pem;     ssl_certificate_key /etc/letsencrypt/live/test-backend.mish.design/privkey.pem;      location / {         proxy_pass http://10.0.0.4:8080;         proxy_set_header Host $host;         proxy_set_header X-Real-IP $remote_addr;         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;         proxy_set_header X-Forwarded-Proto $scheme;     } } } 

Запускаем созданный выше сценарий

scenarios: (100.00%) 1 scenario, 100000 max VUs, 1m30s max duration (incl. graceful stop):          * constant_request_rate: 50000.00 iterations/s for 1m0s (maxVUs: 1000-100000, gracefulStop: 30s)    █ THRESHOLDS       checks     ✗ 'rate>=0.95' rate=89.79%      http_req_duration     ✗ 'p(95)<500' p(95)=3.82s      http_req_failed     ✗ 'rate<0.01' rate=10.20%    █ TOTAL RESULTS       checks_total.......................: 1649228 18316.01633/s     checks_succeeded...................: 89.79%  1480978 out of 1649228     checks_failed......................: 10.20%  168250 out of 1649228      ✗ status is 200       ↳  89% — ✓ 740489 / ✗ 84125     ✗ body contains expected content       ↳  89% — ✓ 740489 / ✗ 84125      HTTP     http_req_duration.......................................................: avg=1.72s min=0s      med=1.73s max=30.09s p(90)=3.32s p(95)=3.82s       { expected_response:true }............................................: avg=1.91s min=4.27ms  med=1.81s max=30.09s p(90)=3.42s p(95)=3.86s     http_req_failed.........................................................: 10.20%  84125 out of 824614     http_reqs...............................................................: 824614  9158.008165/s      EXECUTION     dropped_iterations......................................................: 1154367 12820.183033/s     iteration_duration......................................................: avg=1.81s min=14.05ms med=1.81s max=30.09s p(90)=3.4s  p(95)=3.9s      iterations..............................................................: 824614  9158.008165/s     vus.....................................................................: 1       min=1               max=29297     vus_max.................................................................: 29354   min=2620            max=29354      NETWORK     data_received...........................................................: 231 MB  2.6 MB/s     data_sent...............................................................: 95 MB   1.1 MB/s 

Нагрузка на систему

Основные выводы:

CPU

• Загрузка до ~3000% → задействовано ~30 ядер.

Network Traffic

• Трафик стабильнее, чем у Traefik, но ниже, чем у Envoy.

K6 Test Summary (NGINX)

• Успешные RPS: 9,158 / сек (х2 выше Traefik, но всё ещё ниже цели)

• Ошибки: 10.2% (http_req_failed)

• Дропы: 1,154,367 итераций

• p(95) задержка: 3.82 сек, медиана 1.73 сек

• Макс. задержка: 30 сек (таймаут)

• Передано:

  • Получено: 231 MB (2.6 MB/s)

  • Отправлено: 95 MB (1.1 MB/s)

• VUs: до 29,354 → высокая нагрузка на уровне Traefik.

Вывод:

• NGINX работает лучше Traefik, но сильно уступает HAProxy и Envoy.

• Присутствуют таймауты, высокие задержки и дропы.

Caddy

Это современный веб-сервер и обратный прокси с нативной поддержкой HTTPS и автоматического получения сертификатов от Let’s Encrypt. Главные преимущества Caddy — простота конфигурации, автоматическое управление TLS и минимальные усилия по обслуживанию.

docker-compose.yml

• Запуск через Docker Compose — контейнерный запуск с удобным управлением жизненным циклом.

• Открыты порты 80 и 443 (включая 443/udp для HTTP/3).

• Используется Caddyfile — минималистичная и читаемая конфигурация.

services:   caddy:     image: caddy:latest     container_name: caddy     hostname: caddy     ports:       - "80:80"       - "443:443"       - "443:443/udp"     restart: unless-stopped     volumes:       - caddy_data:/data       - caddy_config:/config       - ./Caddyfile:/etc/caddy/Caddyfile     logging:       driver: "json-file"       options:         max-size: "200k"         max-file: "10"     cap_add:       - NET_ADMIN  volumes:   caddy_data:   caddy_config: 

Caddyfile

• Caddy автоматически берёт и обновляет сертификаты Let’s Encrypt без дополнительных скриптов и настроек.

• Логирование настроено на уровень ERROR для минимальной нагрузки на диск.

• Проксирование запросов на backend-сервис по адресу http://10.0.0.4:8080.

test-backend.mish.design {     log {       level ERROR     }      reverse_proxy http://10.0.0.4:8080 } 

Запускаем созданный выше сценарий

scenarios: (100.00%) 1 scenario, 100000 max VUs, 1m30s max duration (incl. graceful stop):          * constant_request_rate: 50000.00 iterations/s for 1m0s (maxVUs: 1000-100000, gracefulStop: 30s)    █ THRESHOLDS       checks     ✗ 'rate>=0.95' rate=64.12%      http_req_duration     ✗ 'p(95)<500' p(95)=17.03s      http_req_failed     ✗ 'rate<0.01' rate=35.87%    █ TOTAL RESULTS       checks_total.......................: 603996 6708.595341/s     checks_succeeded...................: 64.12% 387296 out of 603996     checks_failed......................: 35.87% 216700 out of 603996      ✗ status is 200       ↳  64% — ✓ 193648 / ✗ 108350     ✗ body contains expected content       ↳  64% — ✓ 193648 / ✗ 108350      HTTP     http_req_duration.......................................................: avg=4.29s min=0s       med=377.57ms max=34.92s p(90)=12.88s p(95)=17.03s       { expected_response:true }............................................: avg=5.03s min=917.98µs med=2.73s    max=31.94s p(90)=12.95s p(95)=16.93s     http_req_failed.........................................................: 35.87%  108350 out of 301998     http_reqs...............................................................: 301998  3354.29767/s      EXECUTION     dropped_iterations......................................................: 1861627 20677.127362/s     iteration_duration......................................................: avg=5.14s min=999.47µs med=477.38ms max=56.43s p(90)=16.17s p(95)=19.59s     iterations..............................................................: 301998  3354.29767/s     vus.....................................................................: 1       min=1                max=28943     vus_max.................................................................: 29170   min=2432             max=29170      NETWORK     data_received...........................................................: 104 MB  1.2 MB/s     data_sent...............................................................: 23 MB   250 kB/s 

Нагрузка на систему

Основные выводы:

CPU

• Загрузка до ~3000% → задействовано ~30 ядер.

Network Traffic

• Пик входящего трафика: ~6–7 MBps, исходящего: ~3–4 MBps

• Колебания присутствуют, особенно в начале — возможны ошибки или нестабильная отдача.

K6 Test Summary (Caddy)

• Успешные RPS: 3,354 / сек → в 15 раз ниже цели

• Ошибки: 35.87% (http_req_failed)

• Дропы: 1,861,627 итераций

• p(95) задержка: 17.03 сек (!), медиана ≈0.4 сек

• Макс. задержка: 34.92 сек

• Трафик:

  • Получено: 104 MB (1.2 MB/s)

  • Отправлено: 23 MB (250 KB/s)

• VUs: до 29,170 — почти на пределе лимита

Вывод:

• Caddy не выдерживает нагрузку в 50k RPS

• Большая доля ошибок, дропов и задержек

• Работает хуже, чем NGINX и Traefik, ближе к антирекорду

Итоги

HAProxy — лидер по стабильности

• Уверенный лидер по результатам тестов: стабильно держит 50 000 rps при минимальной нагрузке на CPU. Прост в запуске и конфиге.

Envoy — почти наравне с HAProxy

• Нагрузка на CPU выше, но приемлемая. Удобен в сценариях, где нужны гибкие настройки маршрутизации.

NGINX — середняк

• Нужен fine-tuning или другой режим работы

• Пропускная способность в 5 раз ниже ожидаемой

• Аномальная нагрузка на CPU

Traefik — нестабилен

• Почти 33% ошибок, сильные дропы, p95 = 8.5 сек.

• Пропускная способность в 5 раз ниже ожидаемой

• Аномальная нагрузка на CPU

Caddy — худший результат

• Самые высокие задержки (p95 = 17 сек), ошибки 36%, дропов >1.8 млн.

• Аномальная нагрузка на CPU

• Явно не справляется с такой нагрузкой в дефолтной конфигурации.

Что важно понять из результатов?

• HAProxy и Envoy — лучшие выборы, если нужна готовая к бою система без плясок с бубном.

• Traefik, NGINX, Caddy — требуют дополнительной настройки и оптимизации для высоконагруженных сценариев.

Для кого подойдёт и зачем всё это использовать?

Когда можно брать HAProxy или Envoy:

• Когда нужен стабильный и производительный балансировщик «здесь и сейчас».

• Минимальные усилия на настройку — запустил и работает.

Когда стоит смотреть на Traefik / NGINX / Caddy:

• Для небольших и средних проектов, где нагрузки ниже и можно позволить себе чуть сложнее конфиг или доработку.

• Если в команде есть человек, который умеет настраивать и оптимизировать эти инструменты под конкретные задачи.

Спасибо что дочитали до конца