Varnish 缓存-无法处理4000个并发用户

Question

在 WP 站点上加载约 4000 个并发用户时遇到此问题。
这是我的配置:

F5 负载均衡器 ---> Varnish 4，8 核，32 Gb RAM ---> 9 个后端，4 个核，每个 16 RAM，运行 WP 站点。

虽然负载约为 2500-3000 个用户，但一切正常，没有任何错误，但是当用户达到 4k 时，varnish 停止响应，直到它计算出所有排队的请求，而且我们看到许多 502 错误。

有 2 个池，每个池 5000 个线程； malloc=30G

另外将 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 会卡住，直到它完成解决所有先前的请求。

所以问题是 - Varnish 并发用户是否有理论上的限制？我如何调整它以处理超过 4k 的并发连接？

PS。还在每个 Apache 服务器上扩展了 MaxClients。

Answer 1

Varnish永远不会产生502返回码，这意味着您很可能不缓存响应。

您很可能会基准化后端。

并发用户数没有内置限制。您的线程数看起来不错。对于仅4000个 session ，您不需要进行任何内核/OS调整，默认值应该很好。如果您使用的是somaxconn，那很可能是基准测试工具的产物，在实际流量中可能不会出现这种情况。

总结:检查命中率并查看varnishlog以确定为什么不缓存内容。