Назад | Перейти на главную страницу

haproxy-varnish не может достичь 6к запросов

Проблема

Я не могу достичь 6 тыс. Запросов в секунду.
У меня много тайм-аутов.
Мое время ответа достигает 26 секунд.

вступление

Я настраиваю сервер, на котором будет размещен статический веб-сайт размером 100 МБ.
Дело в том, что мне придется обрабатывать около 8000 постоянных запросов 5 дней подряд.

Я сделал следующую настройку:

HAProxy -> Varnish -> Nginx -> Staticfiles

HAProxy обрабатывает соединения на порту 80 (скоро и на порту 443), передает запросы Varnish, который будет обслуживать файлы из кеша. Я установил Nginx на expires 7d;. Таким образом, Narnish будет запрашивать статический файл в Nginx каждые 7 дней.

мой сервер настроен так:
Intel (R) Xeon (R) CPU E3-1245 V2 @ 3,40 ГГц
Номер: 8
Кэш: 8192 КБ
Скорость: 1764 МГц
RAM 2 x 8192 МБ

Файлы конфигурации

Nginx

user www-data;
worker_processes 4;
pid /run/nginx.pid;

events {
  worker_connections 768;
}

http {
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 65;
  types_hash_max_size 2048;
  include /etc/nginx/mime.types;
  default_type application/octet-stream;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
  ssl_prefer_server_ciphers on;

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_comp_level 9;
  gzip_buffers 16 16k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;


server {
  listen 127.0.0.1:82 default_server;
  root /var/www/html;

  index index.html index.htm index.nginx-debian.html;
  location / {
    expires 7d;
    add_header Cache-Control "public";
    # First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    try_files $uri $uri/ =404;
  }
}

}

Лак

//DEAMON
DAEMON_OPTS="-a localhost:6081 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -p thread_pools=8 \
             -p thread_pool_min=100 \
             -p thread_pool_max=4000 \
             -s malloc,512m"
//default.vcl
# new 4.0 format.
vcl 4.0;

# Default backend definition. Set this to point to your content server.
backend default {
  .host = "127.0.0.1";
  .port = "82";
}

HAProxy

global
  log /dev/log  local0
  log /dev/log  local1 notice
  chroot /var/lib/haproxy
  stats socket /run/haproxy/admin.sock mode 660 level admin
  stats timeout 30s
  user haproxy
  group haproxy
  daemon
  ca-base /etc/ssl/certs
  crt-base /etc/ssl/private
  ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
  ssl-default-bind-options no-sslv3
  maxconn 65000

defaults
  log global
  mode  http
  option  httplog
  option  dontlognull
  timeout connect 5000
  timeout client  50000
  timeout server  50000
  errorfile 400 /etc/haproxy/errors/400.http
  errorfile 403 /etc/haproxy/errors/403.http
  errorfile 408 /etc/haproxy/errors/408.http
  errorfile 500 /etc/haproxy/errors/500.http
  errorfile 502 /etc/haproxy/errors/502.http
  errorfile 503 /etc/haproxy/errors/503.http
  errorfile 504 /etc/haproxy/errors/504.http

userlist users
  group admin
  user username insecure-password password groups admin

frontend static_https
  bind *:80
  mode http
  acl aclok http_auth_group(users) admin
  #http-request auth realm admin if !aclok
  default_backend static_varnish

backend static_varnish
  mode http
  option forwardfor
  http-request set-header X-Forwarded-Port %[dst_port]
  http-request add-header X-Forwarded-Proto https if { ssl_fc }
  option httpchk HEAD / HTTP/1.1\r\nHost:localhost
  server varnish 127.0.0.1:6081 check

sysctl.conf

net.ipv4.tcp_max_syn_backlog = 10240
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 2048 61000
net.core.netdev_max_backlog = 40000
net.ipv4.tcp_max_tw_buckets = 400000
net.ipv4.tcp_max_orphans = 60000
net.core.somaxconn = 40000

РЕДАКТИРОВАТЬ

loader.io config load test и результат

Ответы

@лиса

Почему HAProxy перед Varnish?

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

Какие нагрузки во время теста?

Я еще не установил инструмент мониторинга, но из последнего проведенного мною теста, посмотрев на htop, я могу сказать:
- прок: 25% ср.
- ОЗУ: 1070 МБ в среднем.

Как ты тестируешь?

Я использую loader.io, он создает 10000 клиентов и заставляет их запрашивать в течение 1 минуты. вы можете увидеть полный тест здесь: http://ldr.io/1eLKrrT

Используете keep-alives?

Не знаю, как работает loader.io.

Какое железо?

Я не могу рассказать вам больше, чем написал выше, если нет способа использовать некоторые команды оболочки?

Пройдет ли тест Accept-Encoding: gzip?

Добавил в loader.io после вашего комментария, ничего не изменил.

Какова частота попаданий в кеш?

Это очень хороший вопрос, но я не знаю, где его посмотреть?

Я начну этот ответ как своего рода открытый ответ. Поскольку я не могу ответить на все сразу и будут дополнительные вопросы.

Во-первых, вы слишком много усложняете. Обслуживание статического контента через nginx, varnish и haproxy, вероятно, вызовет много ненужных накладных расходов (больше TCP-соединений, больше переключателей контента, больше используемой памяти и т. Д.).

Вы можете повысить производительность, используя непосредственно nginx. Поскольку весь ваш контент умещается в памяти, nginx в любом случае будет обслуживать эти файлы из памяти (благодаря кеш-памяти ОС). И используя open_file_cache вы даже можете обойти накладные расходы файловой системы. Varnish, вероятно, может дать вам немного лучшую производительность для простого HTTP.

В вашем случае я бы начал с метода KISS - простого nginx, настройте его на лучшую производительность. Затем добавьте SSL и настройте его на лучшую производительность (keep-alives, кеширование сеанса ssl). Если вы чувствуете, что ваша производительность только с nginx недостаточно хороша, попробуйте выяснить, в чем ваше реальное узкое место и как его можно уменьшить (используя какое программное обеспечение).

И сравнительный анализ. Я бы начал с чего-нибудь местного, например, JMeter, httperf или хотя бы Apache Bench. Это поможет вам исключить все, что есть в Интернете. Как только вы выясните, как ваша установка реагирует на различные виды настройки, используйте что-нибудь вроде loader.io для точной настройки реальной производительности.

Некоторые причины, которые приходят на ум в связи с производительностью, которую вы видите сейчас:

  • вы добавляете задержку к каждому соединению, помещая перед лаком (попробуйте нанести лак напрямую)
  • ваш коэффициент попадания в кеш лака не так хорош, как вы ожидаете, со статическим содержимым он должен быть 100% (используйте varnishstat выяснить)
  • у вас не хватает ресурсов, открытых файловых дескрипторов и т. д.
  • если вы обслуживаете 7000 оборотов в секунду, но получаете 10000 оборотов в секунду, имеется 3000 неотработанных запросов. Вот что вызывает таймауты.
  • ведение журнала тоже может вызвать икоту. Это не должно быть проблемой для Varnish (он использует shm и отдельный процесс), но у меня нет информации о том, как ведется журнал в HAProxy и nginx.
  • мы придумаем больше, я думаю ...