Varnish 4.0 Combat

Introduction

Varnish is a high-performance and open-source reverse proxy server and HTTP Accelerator, with a new software architecture, and now the hardware system closely, compared with the traditional squid, Varnish with higher performance, faster, more convenient management and many other advantages;

The latest version is 4.0.0, and the 3.x version is a stable version that can be used in the production environment, but the 2.x version in the Yum source is too old and is not recommended;

comparison of varnish and squid

same Point

• is a reverse proxy server;

• are open source software;

Advantages of Varnish

• Varnish stability is very high, both in the completion of the same load of work, squid server failure rate is higher than varnish, because the use of squid to often restart;

• Varnish access is faster because with the "Visual page cache" Technology, all cached data is read directly from memory, and squid is read from the hard disk, so varnish is faster in terms of access speed;

• Varnish can support more concurrent connections, because the TCP connection of varnish is faster than squid, so more TCP connections can be supported in high concurrent connections;

• Varnish can use regular expressions to clear part of the cache through the management port, and squid is not available;

• Squid belongs to a single process using a single core CPU, but varnish is the fork to open the multi-process to do processing, so it is reasonable to use all the kernel to handle the corresponding request;

the disadvantage of varnish

• Varnish process once hang, crash or restart, the cache data will be completely released from memory, when all requests are sent to the back-end server, in high concurrency, the backend server will be very stressful;

• In varnish use, if the request of a single URL is balanced by load balancing such as HA/F5, each request falls on a different varnish server, causing the request to be penetrated to the backend, and the same request is cached on multiple servers, resulting in a waste of varnish cache resources. causing performance degradation;

Varnish Disadvantages of the solution

• For disadvantage one: it is recommended to start with Varnish's memory cache in case of heavy traffic, and it needs to be followed by more than one squid server. Mainly in order to prevent the front varnish service, the server is restarted, a large number of requests through the varnish, so squid can serve as a second cache, but also make up for the varnish cache in memory restart will release the problem;

• For disadvantage two: can make a URL hash on load balancer, let a single URL request fixed request to a varnish server;

major improvements compared to Varnish 3.x

• Full support for streaming objects;

• Can obtain the invalid object in the background, namely the client/backend separation;

• A new Vanishlog query language that allows automatic grouping of requests;

• Complex request timestamp and byte count;

• Security improvements;

change points involving the VCL syntax

• VCL configuration file should be explicitly specified version: That is, the first line of the VCL file is written in VCL 4.0;

• The Vcl_fetch function is replaced by vcl_backend_response, and req.* no longer applies to vcl_backend_response;

• Backend Source server group director becomes Varnish module, need to import directors and then define in Vcl_init subroutine;

• A custom subroutine (that is, a sub) cannot start with Vcl_ and calls using call Sub_name;

• The error () function is replaced by synth ();

• Return (lookup) is replaced by return (hash);

• Create FOR_PSS objects using Beresp.uncacheable;

• Variable req.backend.healty is substituted by Std.healthy (req.backend);

• Variable req.backend is substituted by Req.backend_hint;

• The keyword remove is replaced by unset;

See: Https://www.varnish-cache.org/docs/4.0/whats-new/index.html#whats-new-index

Workflow for schema and file caching

• Varnish is divided into master process and child process;

• The master process reads into the storage configuration file, invokes the appropriate storage type, then creates/reads the cache file of the appropriate size, and the master initializes the structure that manages the storage space, then fork and monitor the child process;

• During the initialization of the main thread, the child process mmap the previously opened storage file into memory, creating and initializing the idle structure and suspending it to the storage management structure for allocation;

• The external management interface is divided into 3 kinds, namely command line interface, Telnet interface and Web interface.

• At the same time, the configuration modified during the operation can be compiled by the VCL compiler into the C language, and organized into a shared object, which is used by the child process to load;

The child process allocates several threads to work, mainly including some management threads and many worker threads, which can be divided into:

• Accept thread: Accepts the request and hangs the request on the overflow queue;

• Work thread: There are multiple, responsible for removing the request from the overflow queue, processing the request, until the completion, and then processing the next request;

• Epoll Thread: A request processing is called a session, in the session period, after processing the request, will be handed to epoll processing, monitoring whether there are events;

• Expire thread: For the cached object, according to the expiration time, organized into a binary heap, the thread cycle checks the root of the heap, processing expired files, delete or re-fetch outdated data;

HTTP request basic processing Flow

the process of Varnish processing HTTP requests is as follows

1. Receive status (VCL_RECV): That is, the request processing of the entry state, according to the VCL rules to determine whether the request should pass (Vcl_pass) or pipe (vcl_pipe), or into the lookup (local query);

2. Lookup Status: Enter this state, will find the data in the hash table, if found, then enter the state, otherwise enter the Miss (Vcl_miss) state;

3. Pass (Vcl_pass) Status: In this state, will go directly to the back-end request, that is, into the fetch (Vcl_fetch) state;

4. Fetch (Vcl_fetch) state: In the fetch state, the request carries on the backend obtains, sends the request, obtains the data, and according to the setting carries on the local storage;

5. Deliver (Vcl_deliver) Status: Sends the acquired data to the client and completes the request;

Note: Varnish4 in the vcl_fetch part of a slight discrepancy, has been independent of vcl_backend_fetch and VCL_BACKEND_RESPONSE2 functions;

built-in functions (also called subroutines)

• Vcl_recv: Used to receive and process requests, to be called when a request arrives and successfully received, to determine how the request is processed by judging the requested data;

• Vcl_pipe: This function is called when it enters pipe mode, and is used to Directly to the backend host and return the backend response as it is to the client;

• Vcl_pass: This function is called when it enters pass mode, and is used to pass the request directly to the backend host, but the response from the backend host is not cached directly back to the client;

• Vcl_: After the lookup instruction is executed, the function is automatically called after the requested content is found in the cache;

• Vcl_miss: After the lookup instruction is executed, the requested content is not found in the cache This method is automatically called to determine whether the content needs to be fetched from the backend server,

• Vcl_hash: When a hash value is created for the request after the VCL_RECV call, this function is called This hash value will be used as the key for the search cache object in varnish;

• The function is called after the vcl_purge:pruge operation is executed, and can be used to build a response;

• Vcl_deliver : This method is called before the contents of the requested content in the cache are sent to the client;

• Vcl_backend_fetch: Call this function before sending a request to a back-end host to modify the request to the backend;

• Vcl_ Backend_response: This function can be called after obtaining a response from the backend host;

• Vcl_backend_error: This function is called when the source file fails from the backend host;

• VC This function is called when L_INIT:VCL is loaded, and is often used to initialize the varnish module (vmods)

• Vcl_fini: This function is called when all requests leave the current VCL and the current VCL is discarded. Often used to clean up varnish modules;

public variables built into VCL

variable (also called object) scope of application

Note: Some places differ slightly, in detail can refer to official documents;

Variable Type explanation

• Req:the Request object, variables available when requesting arrival

• Bereq:the backend Request object, variables available for back-end host requests

• Beresp:the backend Response object, variables available when fetching content from the backend host

• Resp:the HTTP Response object, variables available when responding to a client

• OBJ: Available variables related to object properties when stored in memory

Specific variables See: HTTPS://WWW.VARNISH-CACHE.ORG/DOCS/4.0/REFERENCE/VCL.HTML#REFERENCE-VCL

Elegance (Garce mode)

request Consolidation in varnish

When several clients request the same page, Varnish sends only one request to the back-end server, and then makes several other requests pending and waits for the result to be returned;

But if there are thousands of requests at the same time, then this wait queue will become large, which will lead to 2 types of potential problems:

• Panic swarm problem (thundering herd problem), that is, the sudden release of a large number of threads to replicate back-end results, will cause the load to rise rapidly;

• No user likes to wait;

Therefore, in order to solve these problems, the varnish can be configured to return the past file contents (stale content) to the waiting request after the cache object expires due to timeout, and the configuration case is as follows:

Sub vcl_recv {if5melse-sSub Vcl_fetch {more than M # configuration indicates that Varnish will retain the failed cache object for more than 30 minutes, which is equal to the maximum req.grace value; Depending on the health of the backend host, the varnish can provide out-of-date content within 5 minutes or 15 seconds, respectively, to the front-end request

Installation Configuration

# Installation package: http://repo.varnish-cache.org/redhat/varnish-4.0/el6/  YumLocalinstall--nogpgcheck varnish-4.0.0-1. el6.x86_64.rpm varnish-libs-4.0.0-1. el6.x86_64.rpm varnish-docs-4.0.0-1. el6.x86_64.rpmVI/etc/sysconfig/varnish# Edit the configuration file, modify the followingVarnish_storage_size= -M# This value adjusts to its own condition and the test environment can be lowered by this valueVarnish_storage=" malloc,${varnish_storage_size}"  # Varnish 4 uses malloc (that is, memory) as the cache object storage mode by default;Service Varnish Start# boot varnish, default external request for listening port 6081, management port 6082, backend host 127. 0.0. 1: ===========varnishadm-s/etc/varnish/secret-t127.0. 0. 1 :6082 # Login Admin command lineVarnish> vcl.list# List all the configurationsvarnish> vcl.load test1 TEST.VCL# Load compiled new configuration, test1 is the configuration name, TEST.VCL is the configuration fileVarnish> VCL. UseTest1# using configuration, specify the configuration name, the current configuration to use the last vcl.use to prevailVarnish> vcl.show Test1# Display configuration content, specify configuration name

Instance parsing

# # This was an example VCL file  for Varnish. # # It does notDo   anything by default, delegating control to the # builtin VCL. The builtin VCL is called if there is no explicit # return statement. # # See the VCL chaptersIn the Users Guide at   https://www.varnish-cache.org/docs/  # and http://varnish-cache.org/trac/wiki/vclexamples for more examples.  # Marker to tell the VCL compiler that this vcl have been adapted to the # New 4.0 format.Vcl4.0; import Directors;probe Backend_healthcheck {# Create health monitoring  . url =/health.html; . window =5; . Threshold =2; . Interval = 3s;} Backend Web1 {# Create back-end host . Host ="static1.lnmmp.com"; . Port =" the"; . Probe = Backend_healthcheck;} Backend WEB2 { . Host ="static2.lnmmp.com"; . Port =" the"; . Probe = Backend_healthcheck;} Backend IMG1 { . Host ="img1.lnmmp.com"; . Port =" the"; . Probe = Backend_healthcheck;} Backend Img2 { . Host ="img2.lnmmp.com"; . Port =" the"; . Probe = Backend_healthcheck;} Vcl_init {# Create back-end host group, i.e. directors New Web_cluster = Directors.random (); Web_cluster.add_backend (WEB1); Web_cluster.add_backend (WEB2); New Img_cluster = Directors.random (); Img_cluster.add_backend (IMG1); Img_cluster.add_backend (IMG2);} ACL Purgers {# defines accessible source IP  "127.0.0.1";  "192.168.0.0"/ -;} Sub vcl_recv {  if(Req.request = =" GET" && Req.http.cookie) {# A GET request with a cookie header is also cached   return(hash);} if(Req.url ~" test.html" ) {# test.html file Disable caching   return(pass); } if(Req.request = =" PURGE" ) {# Processing of purge requests   if(!client.ip ~ purgers) {   return(Synth (405," Method not allowed" ));  }  return(hash); } if(req.http.x-forward-for) {# Add X-forward-for header for requests from backend hosts   Set req.http.x-forward-for = Req.http.x-forward-for +","+ Client.ip; }Else{  Set req.http.x-forward-for = Client.ip; } if(req.http.host ~" (? i) ^ (www.)? Lnmmp.com$") {# distributed to different backend host group   Set req.http.host =" Depending on the access domain name  www.lnmmp.com";  Set req.backend_hint = Web_cluster.backend (  ); } elsif (req.http.host ~ "  (? i) ^images.lnmmp.com$ ") {   Set req.backend_hint = Img_cluster.backend (); }  return(hash); } Sub vcl_ { # Processing of purge requests  if(Req.request = =" PURGE" ) {  Purge  return(Synth ( $," purged" )); }} Sub vcl_miss { # Processing of purge requests  if(Req.request = =" PURGE" ) {  Purge  return(Synth (404,"Not in  cache" )); }} Sub vcl_pass { # Processing of purge requests  if(Req.request = =" PURGE" ) {  return(Synth (502," PURGE on a passed object" )); }} Sub vcl_backend_response { # The cache length of the custom cache file, that is, the TTL value  if(Req.url ~"\.( jpg|jpeg|gif|png){    Set beresp.ttl = 7200s; } if (req.url ~ "   \. (HTML|CSS|JS) $") {  Set Beresp.ttl = -s; } if(Beresp.http.set-cookie) {# defines a back-end response with Set-cookie header is not cached and is returned directly to the client   return(deliver); }} Sub vcl_deliver {  if(Obj.>0) {# Add X-cache header for response, show cache is   Set Resp.http.x-cache =" from    " + Server.ip; }Else{  Set Resp.http.x-cache =" MISS" ; }}

Varnish 4.0 Combat