Use Varnish to optimize mobile sites

Use Varnish to optimize mobile sites

Imagine that you have just published a blog post and shared it with social networks. Then, this article happened to have been shared by big V. It immediately attracted the eyes of hundreds of fans and guided them into your website. You are excited to see so many visitors and their comments. Suddenly, your website goes down, and the full screen data connection is wrong ......

Or imagine another situation where you have been trying very hard to start a business. Suddenly one day, a big V expressed his love for your company on social networks, and he was amazed by the lines. Follow this big V fans, and then flood into your website. Unfortunately, you cannot access your website after clicking the connection, or you cannot register a user after entering the website, or even get the product serial number when the page times out. Despite your sincere apologies on social networks, there are no more viewers interested.

These assumptions are actually very common. In my work, I often find that when website information is spread across social networks, access requests from mobile devices will surge. This also shows that more and more people are using mobile devices, rather than traditional desktop applications, in social networks. In addition, most mobile users use public Wi-Fi and other low-speed networks to access websites. Therefore, any Optimization Measures to quickly load the website will be conducive to user access.

In this article, I will introduce you to the Varnish Web application accelerator (Varnish Web application accelerator)-a free and simple tool that greatly improves the response capabilities in the case of large-scale, sudden access.

 

Highlights

For most websites, the core content requested by many users is mostly the same-especially for portals that update content every day. Needless to say, you will also understand that, images, CSS and JavaScript, these static resources often have a long validity period (Translator's note: it is helpful to reuse between different pages ). However, you may not have thought deeply. Generally, in a blog platform or content management system, most of the data returned after responding to a user's request is the same.

After a user from a social network enters a blog, the user does not request completely consistent information. In addition to images, JavaScript, and CSS, this information also includes PHP dynamically generated content and data queried from the database. Each request sent to access a blog post is not only to obtain static resources provided by the network server, but also to use PHP scripts, use Database Connection, database form retrieval, and other functions.

The more database connections, the more processes Apache processes need to process, and the total processing capability is limited. Correspondingly, the more visitors there are, the more unstable the service will be and the less money it will earn.

This is where Varnish-like HTTP caching works. In this way, the requests sent from the browser do not go directly to the server that creates and maintains the webpage, but to the HTTP cache server. If the cache server has a required page, the corresponding resources are directly returned from the server's memory and the Apache server and database are no longer used. If the required page is no longer cached, you can use the Apache server to process it in the traditional way. After Apche completes processing, the page will be saved to the HTTP Cache Server, and the next request will return the same page.

Save the page in memory, and the response speed is much faster than saving it in the hard disk. In addition, when the requested page is on the HTTP cache server, you do not need to use PHP or database to handle related operations. This also enables PHP and the server to have more performance to handle more heavy processes and connections. For example, the situation faced by the startup company praised by Big V above, the links clicked by many fans are actually only a few pages on the website-and these can be stored on the cache server and directly respond to requests from the memory when necessary. At this time, the user preparing to register will feel that the entire process is very smooth, because the processing capability of the background script and database connection is very plentiful, completely unaffected by sudden requests.

 

Principle

The following shows the basic process of generating site content after the Apache server responds to the request. In this example, in order to request the same page, a total of five commands are sent to Apache from the browser, and Apache is very rigid in processing each request in detail.

Yes, Apache processes every request-images, CSS, JavaScript, and HTML files. If a file exists in PHP, it will be parsed once. To request database information, perform a data connection and SQL query. Finally, before Apache returns information to the browser, the database returns the page to which the relevant information group is installed.

If Varnish is used between Apache, we can form a process like this:

If the resources and pages requested by the browser already exist in the cache, Varnish will directly return these resources from the memory, and Apache, PHP, and MySql do not need to perform repeated operations at all. If the data requested by the browser is no longer cached, Varnish will transfer the related processing work to Apache to let Apache process the relevant details. The advantage of this method is that only Apache can handle the necessary work. Once the required resources are generated, the resources will be saved to the memory of the cache server. Varnish is fully capable of dealing with these resources when there is another request to access these resources.

This tool has another benefit. In Varnish, the Apache server you configured is called "processing backend ". Varnish allows you to configure multiple processing backgrounds. Therefore, you can run two network servers at the same time, for example, one using Apache to process PHP pages and the other using nginx to process static resources. After successful configuration in Varnish, you can obtain the corresponding resources from the correct server. In this tutorial, we will look at a simple example.

 

Shocked! Teach me now

Installing and configuring Varnish is quite simple. You need to obtain the root permission of the server (sudoTo install Varnish. Therefore, your website must be hosted on a server similar to VPS. Currently, VPS is not so expensive, and Varnish may affect the choice of VPS rather than shared servers.

Some CMS plug-ins can directly use Varnish, or integrate it into the control panel-usually easier to clear the cache. Of course, you can integrate Varnish into any CMS or static website without special configuration.

Before demonstrating the entire process of installing Varnish, I will assume that you have used Apache as the server in the system. Although I am using Debian Linux, the software packages used during installation are also applicable to other distribution versions (but the file paths in the system will be different ).

Before starting, check whether the website runs normally on Apache. If the server you are using is a new product, or you want to try Varnish on a local virtual machine, make sure to configure a virtual host and open the server test page in a browser.

 

Install Varnish

For detailed installation instructions on each platform, see the Varnish official documentation. Because I use Debian Wheezy, I will follow the Debian instructions. Once the installation of Varnish is complete, the following line will be output in the terminal, prompting you that the installation is successful:

1. [ ok ]Starting HTTP accelerator: varnishd.

Apache default listener from80Port Request. This port is used to receive requests. To work with Varnish in the layout prior to Apache, You need to modify the port so that Varnish can listen.80And change the Apache port to a different value.8080. Configure related information in Varnish to connect Varnish to Apache.

 

Reconfigure Apache

To modify the current listening port of Apache, you must userootOpen permission/etc/apache2/ports.confFile, find the following two lines:

1. NameVirtualHost*:80
2. Listen80

To:

1. NameVirtualHost*:8080
2. Listen8080

If you see the following two rows, you only need to modify80Is8080You can:

1. NameVirtualHost127.0.0.1:80
2. Listen80

Save the file and open the default VM file./etc/apache2/sites-available. In this file, find the following line:

1. <VirtualHost *:80>

To:

1. <VirtualHost *:8080>

Of course, you also need to modify other virtual hosts used.

 

Configure Varnish

Open/etc/default/varnishFile to scroll the pageDAEMON_OPTS. Edit this part as follows to make Varnish listen80Port:

1. DAEMON_OPTS="-a :80
2. -T localhost:1234
3. -f /etc/varnish/default.vcl
4. -S /etc/varnish/secret
5. -s malloc,256m"

Open/etc/varnish/default.vclFile, check the Default background port and set it8080To connect to Apache:

1. backend default{
2. .host ="127.0.0.1";
3. .port ="8080";
4. }

InrootRun the following command to restart Apache and Varnish:

1. service apache2 restart
2. service varnish restart

Check whether the previous test page is still accessible. If yes, you may want to know how to test whether the website has been cached on Varnish. In fact, there are several methods, the simplest of which is to use cURL. Enter the following command in the command line:

1. curl http://yoursite.com --head

At this time, the response should be similarVia: 1.1 varnish.

You can also view static resources generated by Varnish. In the terminal, entervarnishstatThen, refresh the page in the browser, and you will see a gradual increase in the click rate. If the resource is provided by Varnish, it is identifiedhitIf it is provided by Apache or another background, it is identifiedmiss.

Another useful tool is varnish-top. First, entervarnishtop -i txurlAnd then refresh the page in the browser. This tool will show which pages are provided by Varnish.

 

Clear Cache

After the page is cached, when you change the HTML or CSS file, you will not immediately see the updated part. This often makes my business trip wrong. Although I know that there was a cache server before Apache, it is still often silly to say "where did I modify it ?" Entervarnishadm "ban.url ."To clear all the caches.

You can also control Varnish over HTTP. There are many plug-ins in this regard. For example, Varnish HTTP Purge serving WordPress can be directly cleared through the management interface.

 

Custom

Maybe you want to fine-tune its configuration by learning how Varnish works. If you configure Varnish according to the above steps, once the static resources and pages are cached in the memory, a large amount of static resources and pages will be accumulated gradually.

Varnish only caches resources that do not affect security, and sometimes does not cache resources that you think will be cached, such as cookies.

In the default configuration, if a cookie is set, Varnish will not cache the corresponding content. Therefore, if your website provides different content for different users, such as personal data, you will not cache all the information for a user. However, sometimes you want to ignore some cookies, such as for some analytical work. If the website does not provide any personal data, the only thing that needs to consider cookies is the background management part. If Varnish caches the background management part, it is inconvenient to view the modification.

Let's modify it./etc/varnish/default.vclFile. Assume that your background management is in/adminTo add the following content:

1. sub vcl_recv {
2. if(!( req.url ~^/admin/)){
3. unset req.http.Cookie;
4. }
5. }

Some cookies may be very important. For example, user cookies that have been logged on should not be cached. Therefore, you do not want to exclude all cookies. Here we use a regular expression to define the cookies that we need. You can also find a lot of solutions to this problem on the Internet. For cookies of analysis tools, you can add the following content:

1. sub vcl_recv {
2. // Remove has_js and Google Analytics __* cookies.
3. set req.http.Cookie= regsuball(req.http.Cookie,"(^|;s*)(_[_a-z]+|has_js)=[^;]*","");
4. // Remove a ";" prefix, if present.
5. set req.http.Cookie= regsub(req.http.Cookie,"^;s*","");
6. }

The Varnish document provides a special section for cookies.

In most cases, configuring Varnish as described above and removing cookies from the analysis tool will greatly speed up Website access. Once Varnish is set up and running, you can fine-tune the configuration and get the best performance from the cache rules.

 

Advanced

For more information, see the Varnish official documentation. From now on, you should try some operation instances to gain a deep understanding of the basic knowledge of Varnish.

Concepts of Cache Server Varnish

Concepts of Cache Server Varnish

Structural notes for Varnish Cache

Install and configure Varnish-5.8 in CentOS 2.1.5

The RedHat script uses the CentOS source to update and install Nginx, PHP 5.3, and Varnish.

Using Varnish to build Cache Server notes

Install and configure the cache service Varnish

Preparations for Varnish compilation and Installation

Configuration Optimization of Varnish cache in Linux

Varnish details: click here
Varnish: click here

This article permanently updates the link address: