【问题标题】:Varnish, What is causing hit-for-pass?清漆,是什么导致了传球?
【发布时间】:2016-05-28 17:53:15
【问题描述】:

这是清漆日志(已编辑 - 扩展以提供更多信息):

*   << Request  >> 172651    
-   Begin          req 172650 rxreq
-   Timestamp      Start: 1455791132.581465 0.000000 0.000000
-   Timestamp      Req: 1455791132.581465 0.000000 0.000000
-   ReqStart       127.0.0.1 47991
-   ReqMethod      GET
-   ReqURL         /
-   ReqProtocol    HTTP/1.1
-   ReqHeader      X-Real-IP: x.x.x.x
-   ReqHeader      X-Forwarded-For: x.x.x.1, x.x.x.2
-   ReqHeader      X-Forwarded-Proto: https
-   ReqHeader      X-Forwarded-Port: 443
-   ReqHeader      Host: mydomain.com
-   ReqHeader      User-Agent: Go-http-client/1.1  (//benchmark app, but regular browser client happens the same
-   ReqHeader      Cf-Connecting-Ip: x.x.x.x
-   ReqHeader      Cf-Ipcountry: AND
-   ReqHeader      Cf-Origin-Https: off
-   ReqHeader      Cf-Ray: 27690752ab232e21-NRT
-   ReqHeader      Cf-Visitor: {"scheme":"https"}
-   ReqUnset       X-Forwarded-For: x.x.x.1, x.x.x.2
-   ReqHeader      X-Forwarded-For: x.x.x.ext, x.x.x.1, x.x.x.2
-   VCL_call       RECV
-   VCL_return     hash
-   VCL_call       HASH
-   VCL_return     lookup
-   Debug          "XXXX HIT-FOR-PASS"
-   HitPass        393349
-   VCL_call       PASS
-   VCL_return     fetch
-   Link           bereq 172652 pass
-   Timestamp      Fetch: 1455791132.581733 0.000268 0.000268
-   RespProtocol   HTTP/1.1
-   RespStatus     200
-   RespReason     OK
-   RespHeader     Server: nginx
-   RespHeader     Date: Thu, 18 Feb 2016 10:25:32 GMT
-   RespHeader     Content-Type: text/html; charset=utf-8
-   RespHeader     Vary: Accept-Encoding, Accept-Encoding
-   RespHeader     Etag: "1455788472-0"
-   RespHeader     Content-Language: ja
-   RespHeader     Cache-Control: no-cache
-   RespHeader     Last-Modified: Thu, 18 Feb 2016 09:41:12 GMT
-   RespHeader     X-Content-Options: nosniff
-   RespHeader     X-Micro-Cache: HIT
-   RespHeader     X-Varnish: 172651
-   RespHeader     Age: 0
-   RespHeader     Via: 1.1 varnish-v4
-   VCL_call       DELIVER
-   VCL_return     deliver
-   Timestamp      Process: 1455791132.581744 0.000279 0.000011
-   RespHeader     Accept-Ranges: bytes
-   RespHeader     Transfer-Encoding: chunked
-   Debug          "RES_MODE 8"
-   RespHeader     Connection: keep-alive
-   Timestamp      Resp: 1455791132.581794 0.000329 0.000049
-   ReqAcct        336 0 336 436 57069 57505
-   End            

我读到这是在设置 set-cookie 标头或设置缓存控制:max-age=0 时创建的。

好吧,我在我的子 vcl_backend_response 中有这个,试图避免通过命中。这很粗鲁,但我不知道后端是什么导致了这个成功:

sub vcl_backend_response {
  unset beresp.http.set-cookie;
  unset beresp.http.expires;
  set beresp.http.Cache-Control = "max-age=6000";
}

我正在摆脱 Expire,因为它被设置为时间戳 0。所以我认为可能是这样。然后我尝试使用 Cache-control 但还是一样。我即将以这种速度取消所有标题...

毕竟是304响应,为什么不缓存呢?

更多信息:后端是 Drupal 应用程序。

编辑1:关于vcl_recv

是的,我确实有一些东西,我正在返回一些路径的通行证(不是我正在检查的路径),我正在取消设置文件的 cookie,并且我正在取消设置其余所有不是 drupal 会话的 cookie。它是mroe或更少的复制/粘贴drupal默认子vcl_recv。如果你愿意,我可以在这里复制。

顺便说一句,我改变了其他东西,现在我在响应 200 中也被击中通过(但是当我使用基准工具时)。有人删除了可能是因为响应 304 的答案。我正在检查,但答案不见了:(

好的,这里是 vcl_recv:

sub vcl_recv {
 if (req.url ~ "^/status\.php$" ||
    req.url ~ "^/admin/.*$" ||
     [...]
     req.url ~ "^.*\.js.*$" ) 
    {
       return (pass);
    }

  if (req.url ~ "^/admin/content/backup_migrate/export") {
    return (pipe);
  }

  ## COOKIES ##
  if (req.url ~ "(?i)\.(css|js|jpg|jpeg|gif|png|ico|svg|map)(\?.*)?$") {
    unset req.http.Cookie;
  }
  if (req.http.Cookie) {
    set req.http.Cookie = ";" + req.http.Cookie;
    set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";"); 
    set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]+|SSESS[a-z0-9]+|NO_CACHE)=", "; \1=");
    set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
    set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");
   if (req.http.Cookie == "") {
        unset req.http.Cookie;
    }
    # if any of our cookies of interest are still there, we disable caching and pass the request
    else {
        return (pass);
    }
 }
}

它几乎总是在所有 http. 304 个响应和 200 个响应。我已经编辑了上面的 varnishlog 以显示一个完整的示例以提供更多信息。

编辑: 因此,这是请求显示成功通过之前的日志。肯定是把命中设置为传球的罪魁祸首:

-   ReqHeader      X-Forwarded-For: 127.0.0.1
-   VCL_return     hash
-   VCL_call       HASH
-   VCL_return     lookup
-   VCL_call       MISS
-   VCL_return     fetch
-   Link           bereq 3 fetch
-   Timestamp      Fetch: 1456731597.992472 0.099948 0.099948
-   RespProtocol   HTTP/1.1
-   RespStatus     200
-   RespReason     OK
-   RespHeader     Date: Mon, 29 Feb 2016 07:39:57 GMT
-   RespHeader     Content-Type: text/html; charset=utf-8
-   RespHeader     Content-Encoding: gzip
-   RespHeader     Vary: Accept-Encoding
-   RespHeader     Etag: "1456730796-0"
-   RespHeader     Content-Language: ja
-   RespHeader     Cache-Control: no-cache
-   RespHeader     Last-Modified: Mon, 29 Feb 2016 07:26:36 GMT
-   RespHeader     Expires: Thu, 01 Jan 1970 00:00:01 GMT
-   RespHeader     X-Content-Options: nosniff
-   RespHeader     X-Micro-Cache: EXPIRED
-   RespHeader     X-Varnish: 2
-   RespHeader     Age: 0
-   RespHeader     Via: 1.1 varnish-v4
-   RespUnset      Etag: "1456730796-0"
-   RespHeader     ETag: W/"1456730796-0"
-   VCL_call       DELIVER
-   RespHeader     X-Cache: MISS
-   RespHeader     X-Cache-Hits: 0
-   RespUnset      X-Varnish: 2
-   RespUnset      Via: 1.1 varnish-v4
-   VCL_return     deliver
-   Timestamp      Process: 1456731597.992517 0.099993 0.000044
-   RespUnset      Content-Encoding: gzip
-   RespHeader     Accept-Ranges: bytes
-   RespHeader     Content-Length: 53980
-   Debug          "RES_MODE 42"
-   RespHeader     Connection: keep-alive
-   Gzip           U D - 12752 53980 80 101936 101946
-   Timestamp      Resp: 1456731597.992817 0.100293 0.000300
-   ReqAcct        746 0 746 437 53980 54417

【问题讨论】:

  • 你的 vcl_recv 里有什么东西吗?
  • @jdewald 是的,我有东西,但只是默认的 drupal 东西,你要我复制粘贴吗?
  • vcl_hash 怎么样?从 Varnish 的输出中,似乎表明缓存的对象已经是一个 hit-for-pass 对象,这表明缓存到同一个键的至少一个东西是一个 hit-for-pass。可能发生的一种方法是,如果您有一个请求,其中一个“有趣”cookie 包含在一个请求中(不一定是这个),该请求完成并设置了一次通过。
  • 嗨@jdewald,如果您查看我的最后一次编辑,您会看到之前的请求在我被击中通过之前正在做什么。 (我只是把响应部分)。有什么地方引起你的注意是错误的吗?谢谢你看看这个
  • 在您显示的请求中,它最终具有“无缓存”Cache-Control 标头,但您的 VCL 将其设置为更高。那是针对相同的内容吗?

标签: varnish varnish-4


【解决方案1】:

这个问题太长了,恐怕对其他人也没有用处。

感谢其他答案给出的链接,我看到了这个(vcl_backend_response 的默认实现):

sub vcl_backend_response {
if (beresp.ttl <= 0s ||
    beresp.http.Set-Cookie ||
    beresp.http.Surrogate-control ~ "no-store" ||
    (!beresp.http.Surrogate-Control &&
    beresp.http.Cache-Control ~ "no-cache|no-store|private") ||
    beresp.http.Vary == "*") {
    /*
     * Mark as "Hit-For-Pass" for the next 2 minutes
     */
    set beresp.ttl = 120s;
    set beresp.uncacheable = true;
}
return (deliver);
}

这都是导致击中传球的所有条件。多亏了这一点,我可以看到导致通过命中的正是这个 beresp.ttl

那么,beres.ttl 是哪个值?在同一个链接上,我们读到:beresp.ttl 使用它在其中找到的第一个值进行初始化:

The s-maxage variable in the Cache-Control response header field
The max-age variable in the Cache-Control response header field
The Expires response header field
The default_ttl parameter.

修改vcl_backend_response中的headers没关系,因为ttl已经设置好了!

好吧,看看我的标题,我可以从后端看到:

 -  RespHeader Expires: Thu, 01 Jan 1970 00:00:01 GMT

这是什么导致了传球命中。这就是我的问题的答案。现在,为什么我有这个我不知道的标题,那将是一个不同的问题。 (我修改了 nginx 的 expires 30d; 到所有没有结果的位置)

【讨论】:

【解决方案2】:

可能是您的问题正是它是 304 响应:

清漆 3 书说:

默认只缓存以下状态码:

200: OK
203: Non-Authoritative Information
300: Multiple Choices
301: Moved Permanently
302: Moved Temporarily
307: Temporary Redirect
410: Gone
404: Not Found

您仍然可以缓存其他状态代码,但您必须设置 beresp.ttl 到 vcl_fetch 自己的正值。

http://book.varnish-software.com/3.0/VCL_Basics.html

令我惊讶的是,Varnish 4 书中还提到“304:未修改”是可缓存的。 http://book.varnish-software.com/4.0/chapters/VCL_Basics.html

这对我来说没有意义,因为如果 Varnish 缓存了条件请求的 304 响应,那么对同一资源的每个非条件请求也应该得到没有响应主体的 304 响应,这似乎毫无用处。

【讨论】:

    猜你喜欢
    • 2012-09-23
    • 1970-01-01
    • 2015-04-13
    • 2014-04-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-08-10
    相关资源
    最近更新 更多