Опытная проблема при загрузке ~ 4000 одновременно работающих пользователей на сайте WP. Вот конфигурация, которую у меня есть:Varnish cache - не может обрабатывать 4000 одновременных пользователей
F5 loadbalancer ---> Varnish 4 с 8 ядрами, RAM 32 ГБ ---> 9 backend с 4 ядрами, по 16 RAM каждый, работающий WP сайт.
В то время как нагрузка составляет ~ 2500-3000 пользователей, все идет нормально, без каких-либо ошибок, но когда пользователи достигают 4k, лак перестает отвечать, пока не вычислит все запрошенные в очереди запросы, плюс мы увидим много ошибок 502.
Имейте 2 бассейна по 5000 нитей; таНос = 30G
Additionaly добавил SOMAXCONN и TCP_MAX_SYN_Backlog в SYSCTL
Вот VCL:
vcl 4.0;
import directors;
import std;
backend qa2 { .host = "xxx"; .port = "80"; }
backend qa3 { .host = "xxx"; .port = "80"; }
backend qa4 { .host = "xxx"; .port = "80"; }
backend qa5 { .host = "xxx"; .port = "80"; }
backend qa6 { .host = "xxx"; .port = "80"; }
backend qa7 { .host = "xxx"; .port = "80"; }
backend qa8 { .host = "xxx"; .port = "80"; }
backend qa9 { .host = "xxx"; .port = "80"; }
backend qa10 { .host = "xxx"; .port = "80"; }
# .connect_timeout = 2s; .first_byte_timeout = 10m; .between_bytes_timeout = 10m;
acl purge_list {
"xxx";
"xxx";
"xxx";
"xxx";
"xxx";
"xxx";
"xxx";
"xxx";
"xxx";
"xxx";
}
sub vcl_init {
new rr = directors.round_robin();
rr.add_backend(qa2);
rr.add_backend(qa3);
rr.add_backend(qa4);
rr.add_backend(qa5);
rr.add_backend(qa6);
rr.add_backend(qa7);
rr.add_backend(qa8);
rr.add_backend(qa9);
rr.add_backend(qa10);
}
sub vcl_recv {
set req.backend_hint = rr.backend();
if (req.method == "PURGE") {
if (!client.ip ~ purge_list) {
return(synth(405, "not allowed."));
}
ban("req.url ~ .css");
return(synth(200, "CSS Files Cleared from Cache!"));
}
# Don't check cache for POSTs and various other HTTP request types
if (req.method != "GET" && req.method != "HEAD") {
#ban("req.http.host == " + req.http.host);
return(pass);
}
# Don't check cache for POSTs and various other HTTP request types
if (req.http.Cookie ~ "SESS[a-f|0-9]+" ||
req.http.Authorization ||
req.url ~ "login" ||
req.method == "POST" ||
req.http.Cookie ||
req.url ~ "/wp-(login|admin)") {
return (pass);
}
if (req.http.Accept-Encoding) {
if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") {
unset req.http.Accept-Encoding;
} elsif (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = "deflate";
} else {
unset req.http.Accept-Encoding;
}
}
if (req.url ~ "\.(aif|aiff|au|avi|bin|bmp|cab|carb|cct|cdf|class|css)$" ||
req.url ~ "\.(dcr|doc|dtd|eps|exe|flv|gcf|gff|gif|grv|hdml|hqx)$" ||
req.url ~ "\.(ico|ini|jpeg|jpg|js|mov|mp3|nc|pct|pdf|png|ppc|pws)$" ||
req.url ~ "\.(swa|swf|tif|txt|vbs|w32|wav|wbmp|wml|wmlc|wmls|wmlsc)$"||
req.url ~ "\.(xml|xsd|xsl|zip|woff)($|\?)") {
unset req.http.Cookie;
#unset req.http.Authorization;
#unset req.http.Authenticate;
return (hash);
}
return(hash);
}
# Cache hit: the object was found in cache
sub vcl_hit {
if (req.method == "PURGE") {
return (synth(200, "Purged!"));
}
}
# Cache miss: request is about to be sent to the backend
sub vcl_miss {
if (req.method == "PURGE") {
return (synth(200, "Purged (Not in cache)"));
}
}
sub vcl_backend_response {
if (bereq.url ~ "\.(aif|aiff|au|avi|bin|bmp|cab|carb|cct|cdf|class|css)$" ||
bereq.url ~ "\.(dcr|doc|dtd|eps|exe|flv|gcf|gff|gif|grv|hdml|hqx)$" ||
bereq.url ~ "\.(ico|ini|jpeg|jpg|js|mov|mp3|nc|pct|pdf|png|ppc|pws)$" ||
bereq.url ~ "\.(swa|swf|tif|txt|vbs|w32|wav|wbmp|wml|wmlc|wmls|wmlsc)$"||
bereq.url ~ "\.(xml|xsd|xsl|zip|woff)($|\?)") {
set beresp.grace = 30s;
set beresp.ttl = 1d;
set beresp.http.Cache-Control = "public, max-age=600";
set beresp.http.expires = beresp.ttl;
return (deliver);
}
}
# Deliver the response to the client
sub vcl_deliver {
# Add an X-Cache diagnostic header
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT";
set resp.http.X-Cache-Hits = obj.hits;
# Don't echo cached Set-Cookie headers
unset resp.http.Set-Cookie;
} else {
set resp.http.X-Cache = "MISS";
}
# Remove some headers not needed on production systems
# unset resp.http.Via;
# unset resp.http.X-Generator;
# return(deliver);
}*
А вот результаты последнего теста:
На самом деле время отклика хорошее, но пропускная способность плохая, и, как я уже писал, Varnish зависает, пока не завершит решение всех предыдущих запросов.
Итак, вопросы: есть ли теоретический предел для лаковых параллельных пользователей? Как настроить его для работы с более чем 4k параллельными соединениями?
PS. Также расширены MaxClients на каждом сервере Apache.
Да, жаль я не говоря уже о том, что hitrate просто отлично, более 90% HIT, поэтому лак обычно кэшируется. Между тем, загрузка бэкэндов не превышает 60-70% на каждой машине, все кажется хорошим. Есть предположения? –