Varnish 4.0 Official document translation 22-varnish Website Performan

Varnish and Website Performance

This section focuses on how to tune varnish server and how to use varnish to optimize your Web site.

There are three bars. The first section you should think of the various tools and functions of varnish, the next section how to clear the cached content from the cache. Clearing content is a basic feature because it allows you to add TTL to cached objects. The larger the TTL, the longer the varnish remains in the cache, which means that varnish processes more requests and passes only a small portion of the request to a relatively slow back end.

The last section deals with the compression of Web content. When you get content from the backend, varnish can compress it, and then pass the compressed content. This way, you can reduce the time of your customer's current content and improve the performance of your Web site.

Achieving a high hitrate

Now that varnish is up and running, you can access your Web application through varnish. Unless your application is specifically designed to work behind a network accelerator, you may need to make some changes to the varnish configuration or application to increase the hit rate of varnish.

Varnish does not cache your data unless it is absolutely certain that the operation is secure. So, for you to understand how varnish decides whether and how to cache pages, we will guide you through some tools, and you can find some tools to understand what's going on in Varnish's configuration.

Note that you need a tool to view the HTTP headers across the varnish and back ends. In the varnish server, the simplest method is to use Varnishlog and varnishtop, but sometimes the client tools are also meaningful. These tools are common to us.

Tool:varnishtop

You can use Varnishtop to find out what URLs are being hit. varnishtop-i Berequrl is the basic command that shows you the top request varsnih sent to the backend. You can view the other columns of the varnishtop usage in Statistics .

Tool:varnishlog

When you find a URL that is frequently sent to the backend, you can use Varnishlog to view the request. varnishlog-q ' Requrl ~ ' ^/foo/bar ' shows you the request from the client to match to /foo/bar .

For more information on how Varnishlog works, see Logging in Varnish or the man manual for Varnishlog.

Extended HTTP header,http://www.varnish-cache.org/trac/wiki/VCLExampleHitMissHeader

Tool:lwp-request

Lwp-request is a tool in the Perl www library. A basic program that can send a request to show you the results at the same time. The tool is primarily looking at HTTP response headers. Many tools can be implemented. Like the curl tool that comes with Linux.

# curl-i http://vg.no/HTTP/1.1 301 Moved permanentlyserver:apache/2.2.15 (CentOS) X-vg-webserver: vgphoenix-web-02location:http://www.vg.no/content-type:text/html; Charset=iso-8859-1x-vg-solveme:uggc://jjj.it.ab/ynxfrgngg.ugzydate:mon, 03:28:46 GMTConnection: keep-alivex-cache:hit:40vary:accept-encoding,user-agentx-vg-webcache:hmg9-varnish-01x-age:46age:0

Also Firefox's Firebug tool can be viewed with Chrome's own tools.

Cookies

By default, varnish does not cache objects with Set-cookie in the HTTP header from the back-end response. If the client sends a request with a cookie Header,varnish will ignore the cache and pass the request directly to the backend.

This may be a multi-degree conservative. A large number of sites use Google Analytics to analyze their traffic, and GA sets cookie information to track you. The cookie is used by the client's JS and is not of interest to the server.

Cookies from the client

It is meaningful for a large number of Web applications to be fully aware of a cookie unless you specify a part of the Web site that does not need to ignore cookies.

VCL fragments in vcl_recv will ignore cookies unless you access URLs that match to/admin/

if (! ( Req.url ~ "^/admin/")) {unset Req.http.Cookie;}

Quite simple. However, if you need to do something complicated, like removing one of several cookies, it becomes difficult. Unfortunately, Varnish does not have some good tools to manipulate cookies. We have to use regular expressions to do this. If you are familiar with regular expressions you will understand what is going on, or we suggest you look at Pcrepattern (pcre-perl-compatible regular expressions) or view a rich online document.

Let's take a look at the example of varnish software (VS). Very concise settings, varnish cache in the front end, the backend uses drupal-based. vs using some cookies that track Google Analytics there are some other similar tools. All cookies become a collection that is used by JS. Neither varnish nor Drupal need to view these cookies, and since the client sends a cookie to varnish,varnish terminates the cached page, varnish needs to discard unnecessary cookies in the VCL.

In the following VCL we discard all cookies starting with the following underscore:

# Remove Has_js and Google Analytics __* cookies.set req.http.Cookie = Regsuball (Req.http.Cookie, "(^|;\ s*) (_[_A-Z]+|HAS_JS) =[^;] * "," "); # Remove a"; "prefix, if present.set Req.http.Cookie = Regsub (Req.http.Cookie," ^;\s* "," ");

In the following example, we remove all cookies except for the name COOKIE1 and COOKIE2, and you will be amazed to find that it is so perfect:

sub vcl_recv {    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 ,  ";(cookie1| COOKIE2) = ", ";  \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;         }    }} 

 sub vcl_recv {    # save the original cookie  Header so we can mangle it    set req.http.x-varnish-php_sid  = req.http.cookie;    # using a capturing sub pattern,  extract the continuous string of    # alphanumerics  that immediately follows  "Phpsessid="     set req.http.x-varnish-php_ Sid =        regsuball (req.http.x-varnish-php_sid,  ";?  ? Phpsessid= ([a-za-z0-9]+) ( |;|  ;). * "," \1 ");     set req.http.cookie = req. X-varnish-php_sid;    unset req. X-varnish-php_sid;} 

There are more surprising examples of what Varnish can do in VCL in the Varnish Cache Wiki .

Cookies coming from the backend

With the default settings, if the backend server has a Set-cookie header set, varnish will not cache the content. A Hit-for-pass object is created. So if the backend behaves strangely and sets some unwanted cookie,unset ' set-cookie ' headers, everything will be OK.

Cache-control

The Cache-control header notifies the cache of how the content is handled. Varnish cares about the ' max-age ' parameter, and it is used to calculate the TTL of an object.

Therefore, make sure you set the ' Cache-control ' header with Max-ag. You can look at the response of Varnish software drupalserver.

$ curl-i http://www.varnish-software.com/|grep ' Cache-control ' cache-control:max-age=1209600

Age

Varnish adds the ' age ' header to indicate how long the object has been Varnish cached. You can use * varnishlog-i respheader:^age* to filter out age from Varnishlog.

Pragma

HTTP 1.0server may send pragma:nocache headers. Varnish ignores pragma headers. You can easily add support for the pragma head. In VCLbackendresponse:

if (beresp.http.Pragma ~ "NoCache") {set beresp.uncacheable = true; Set beresp.ttl = 120s; # How long isn't to the cache this URL.}

Authorization

If Varnish sees a ' Authorization ' header in the header, it will pass the request. If you don't need this head, you can unset.

Overriding the Time-to-live (TTL)

Sometimes your back end will be downwind. In varnish you can easily rewrite the TTL, and then you fix your cumbersome back end. You need to specify the object you want to set in the VCL, and then set ' Beresp.ttl '

Sub Vcl_backend_response {if (bereq.url ~ "^/legacy_broken_cms/") {Set beresp.ttl = 5d; }}

Forcing caching for certain requests and certain responses

Your backend may still be cumbersome and not working well, and you may want to store more resources to varnish. We recommend that you rely on as many default cache rules as possible. Forcing varnish to find objects in the cache is easy, but it's not really a recommendation.

Normalizing your namespace

Some sites have many domain names. http://www.varnish-software.com/, Http://varnish-software.com/and http://varnishsoftware.com/all point to the same site. And Varnish didn't know they were the same. Varnish will cache different versions of the same object depending on the domain name. You can slow down this situation by configuring redirect in webserver or using the following VCL:

if (req.http.host ~ "(? i) ^ (www.)? Varnish-?software.com ") {Set req.http.host =" varnish-software.com ";}

HTTP Vary

HTTP Vary is not a trivial concept. This is by far the most misunderstood HTTP header.

A large number of response headers tell the client whether the HTTP object should be passed. Clients can choose to request different HTTP objects based on their preferences. Their parameter choices include like coding and domain names. When the client prefers UK 中文版, it is indicated by Accept-language:en-uk . The cache needs to be kept in a different version, implemented through the ' Vary ' header in the response.

When the backend server is vary:accept-language labeled, it tells Varnish to save different versions for each different accept-language.

If two clients accept "en-us, En-uk" and "Da, de" respectively, and if the backend indicates that different accept-language,varnish will be cached and provide two different versions.

Please note that the vary header needs to be fully matched. So if vary is "en-us, En-uk" and "En-us,en-uk" (multiple spaces), varnish will save two copies of the same page.

The key is to standardize the backend header when using vary while getting the hit rate. Remember that even a little difference can lead to different cache entries.

The following VCL code will standardize the Accept-language header, regardless of "en", "de" or "fr", in this order of precedence.

 if  (req.http.accept-language)  {    if  (req.http.accept-language ~   "en")  {        set req.http.accept-language =   "en";    } elsif  (req.http.accept-language ~  "de")  {         set req.http.Accept-Language =  "de";     } elsif  (req.http.accept-language ~  "fr")  {         set req.http.Accept-Language =  "FR";    } else  {        # unknown language. remove the  accept-language header and        # use the  backend default.        unset req.http.accept-language     }} 
 

Vary Parse Errors

If varnish resolves vary header error, a 503 network error will be returned. Or the client's head size exceeds 65k. In this case, the Slt_error log is incremented.

Pitfall-vary:user-agent

User-agent's trap.

Some applications or application servers that send ' vary:user-agent ' along with content. This behavior informs varnish to cache individual copies of each ' User-agent ' version. Instant is a single patch version of the same browser with at least 10 different user-agent for different running operating systems.

If you really need to diversify based on user-agent, be sure to initialize the standardized header or you can tolerate varnish's hit rate. Use the above code as a template.

Varnish 4.0 Official document translation 22-varnish Website Performan