Я не могу достичь 6 тыс. Запросов в секунду.
У меня много тайм-аутов.
Мое время ответа достигает 26 секунд.
Я настраиваю сервер, на котором будет размещен статический веб-сайт размером 100 МБ.
Дело в том, что мне придется обрабатывать около 8000 постоянных запросов 5 дней подряд.
Я сделал следующую настройку:
HAProxy -> Varnish -> Nginx -> Staticfiles
HAProxy обрабатывает соединения на порту 80 (скоро и на порту 443), передает запросы Varnish, который будет обслуживать файлы из кеша. Я установил Nginx на expires 7d;
. Таким образом, Narnish будет запрашивать статический файл в Nginx каждые 7 дней.
gzip_comp_level 9;
. expires 7d;
. thread_pools=8 thread_pool_max=4000
. malloc,512m
. maxconn 65000
. maxconn 65000
не душит. Я думаю, что Varnish сдерживает мои запросы, но я не знаю, как это подтвердить. мой сервер настроен так:
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
@лиса
Почему 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 для точной настройки реальной производительности.
Некоторые причины, которые приходят на ум в связи с производительностью, которую вы видите сейчас:
varnishstat
выяснить)