Optimizing mobile-side access using varnish on the Apache server _linux

Imagine that you've just posted a blog post and shared a social network. Then, this article happened to be the Big V fancy again to share out, immediately attracted hundreds of of fans eyes, guide them into your site. You are thrilled to see so many visitors and their comments. All of a sudden, your site is hung up, full screen data connection error ...

Or imagine another situation where you've been working very hard to start a business. Suddenly one day, a big V in the social network to express the love of your company, between the words full of admiration. Attention to this big V fans heart, and then poured into your website. Unfortunately, click on the connection but can not enter your site, or enter after the user can not register, or even the page corresponding timeout, can not get the product serial number. Although you are sincerely apologetic about this on the social network, many viewers will not be interested.

These assumptions are actually very common. In my work, it is often found that when the Web site information on the social networking site, mobile device access requests will be a surge. It also shows that in social networks, more and more people are starting to use mobile devices rather than traditional desktop applications. In addition, most mobile users use public Wi-Fi and other low-speed networks to access the site. Therefore, the rapid loading of any site optimization measures, will be conducive to user access.

In this article, I'll introduce you to the Varnish Web application accelerator (Varnish Web application Accelerator)--a free, simple tool that dramatically improves responsiveness in a large burst of access state.
Highlights

For most Web sites, most of the core content that many users request access to is consistent-especially the portal that updates content every day. Needless to say, you'll understand, too. Pictures, CSS, and JavaScript, these static resources tend to have a longer validity period (translator Note: Useful for reuse between different pages). But you may not think deeply, usually in the blog platform or content management system, in response to the user's request, the returned data content, mostly the same.

Users from a social network who enter a blog will not ask for exactly the same information. In addition to pictures, JavaScript, and CSS, this information includes dynamically generated content from PHP, as well as data that is queried from the database. To access a blog post, every request that needs to be sent is not only to obtain the static resources provided by the network server, but also to cooperate with PHP scripts, use database connection and database form retrieval functions.

The more database connections there are, the more processes the Apache needs to handle, and the total processing power is limited. Accordingly, the more visitors, the more unstable the service will be, the less money will be earned.

This is where HTTP caching works like varnish. As a result, requests made from the browser no longer go directly to the server that created and maintained the Web page, but to the HTTP cache server. If the desired page exists in the cache server, the corresponding resources are returned directly from the server's memory, and the Apache server and database are no longer used. If the desired page is no longer cached, it is handled using the Apache server as in the traditional way. Once the Apche process is complete, the page is saved to the HTTP cache server, and can be returned directly the next time the same page is requested.

Saving a page in memory is much faster than saving it on your hard disk. In addition, when the requested page is in the HTTP cache server, there is no need to use PHP or the database to handle the related operations. This also allows PHP and the server to have more performance to handle more onerous processes and connections. For example, the situation that the start-up that was praised by Big V, mentioned above, is that many fans click on a few pages of the site--which can be stored in a cache server and respond directly to requests from memory when needed. At this point, the user who is ready to register will feel the whole process is very smooth, because the background script and the database connection processing ability is very comfortable, completely is not affected by the abrupt request.
principle

The following diagram shows the basic process of generating site content after the Apache server responds to requests. In this example, in order to request the same page, a total of five instructions from the browser sent to Apache, and Apache is very inflexible to each request to do a detailed processing.

Yes, Apache handles every request-images, css,javascript, and HTML files. If you have a file in PHP, it is parsed once. If you need to request information about the database, you should perform a data connection, SQL query, and so on. Finally, before Apache returns to the browser information, the database returns the relevant information and assembles it into a finished page.

If we use varnish between Apache, we can form a process like this:

If the resources and pages requested by the browser already exist in the cache, then varnish will return these resources directly from memory, and Apache, PHP, and MySql do not need to repeat the operation at all. If the browser requests data is no longer cached, then varnish will transfer the relevant processing work to Apache, let Apache handle the relevant details. The advantage of this approach is that only Apache handles the necessary work, and once the required resources are generated, the resource is saved to the cached server's memory. Once again requesting access to these resources, varnish is fully capable of coping.

There is another benefit to this tool. In the varnish, the Apache server you configure is called "Processing backstage." Varnish allows you to configure multiple processing backgrounds. So, you can run two Web servers at the same time, for example, one uses Apache to process PHP pages, and one uses Nginx to handle static resources. Once you have set up successfully in varnish, you can obtain the appropriate resources from the correct server. In this tutorial, we will look at a simple example.
Shocked! Just teach me.

Installing and configuring varnish is fairly straightforward. You need to get the server root (sudo) to install varnish. Therefore, your site needs to be hosted on a VPS-like server. Now the price of VPS is not so expensive, and the use of varnish will also affect the choice of VPS rather than shared server.

Some CMS-owned plug-ins can either use varnish directly or integrate them into the control panel--it's usually easier to empty the cache. Of course, you can integrate varnish into any CMS or static Web site without the need for a special configuration.

Before I demonstrate the entire process of installing varnish, I assume you've already used Apache as a server in your system. Although I am using Debian Linux, the packages used during the installation are also applicable to other distributions (only the file paths in the system will be different).

Before you start, check to see if the site is working on Apache. If the server you are using is a new product, or if you want to try varnish on a local virtual machine, be sure to configure a virtual host and use the browser to open the test page for that server.
Install varnish

Please refer to varnish official documentation for detailed installation instructions for each platform. Because I'm using a Debian wheezy, I'll follow the Debian section's instructions. Once the varnish installation is complete, the following paragraph will be printed in the terminal, prompting you to install successfully:

Copy Code code as follows:

[OK] Starting HTTP accelerator:varnishd.

Apache listens for requests from port 80 by default. This port receives requests, so in order to match the layout of the varnish before Apache, you need to modify the port so that varnish listens on port 80 and modifies the Apache port to a different value-typically 8080. Then configure the relevant information in the varnish to let the varnish connect to Apache.
Reconfigure Apache

In order to modify the current listening port for Apache, you need to open the/etc/apache2/ports.conf file with root permission to find the following two lines:

Copy Code code as follows:

Namevirtualhost *:80
Listen 80

Modified to:

Copy Code code as follows:

Namevirtualhost *:8080
Listen 8080

If you see the following two lines, you only need to modify 80 to 8080:

Copy Code code as follows:

Namevirtualhost 127.0.0.1:80
Listen 80

Then save the file and open the default virtual host file, which should be in/etc/apache2/sites-available. In this file, locate the following line:

Copy Code code as follows:

<virtualhost *:80>

Modified to:

Copy Code code as follows:

<virtualhost *:8080>

Of course, you also need to modify other virtual host used.
Configure varnish

Open the/etc/default/varnish file and scroll the page to a section that does not have a comment and begins with a daemon_opts. Edit this section as follows so that varnish listens on port 80:

Copy Code code as follows:

Daemon_opts= "-a:80
-T localhost:1234
-f/etc/varnish/default.vcl
-s/etc/varnish/secret
-S malloc,256m "

Open the/etc/varnish/default.vcl file, check the default backend port and set to 8080 to connect Apache:

Copy Code code as follows:

Backend Default {
. Host = "127.0.0.1";
. Port = "8080";
}

Under root permissions, restart Apache and varnish with the following command:

Copy Code code as follows:

Service Apache2 Restart
Service Varnish Restart

Check to see if the previous test page is still connected. If you can, then you may want to know how to test whether the site has been cached on the varnish. In fact there are several ways, the simplest is the use of CURL. Please enter the following command at the command line:

Copy Code code as follows:

Curl Http://yoursite.com--head

Getting a response at this point should resemble the via:1.1 varnish.

You can also view the static resources generated by varnish. In the terminal, enter the Varnishstat, and then refresh the page in the browser, you will see a gradual increase in the click rate. If the resource is provided by the varnish, it will be identified as hit and, if supplied by Apache or other background, identified as Miss.

Another useful tool is varnish-top. First enter Varnishtop-i txurl on the command line, and then refresh the page in the browser. This tool will show which pages are provided by varnish.
Clear Cache

When the page is cached, when you change the HTML or CSS file, you do not see the updated part immediately. This often makes me travel wrong. Although I knew there was a cache server before Apache, it was always stupid. "Where's my change?" "Enter Varnishadm at the command line Ban.url." To clear all the caches.

You can also control varnish via HTTP. There are many plug-ins in this area, such as the varnish HTTP Purge service in WordPress, you can clear the cache directly through the admin interface.
Custom

Perhaps you'll want to fine-tune its configuration by understanding some of the varnish's working principles. If you configure varnish according to the above steps, once static resources and pages are cached in memory, a large number of static resources and pages are accumulated gradually.

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

In the default configuration, if a cookie is set, then varnish does not cache the appropriate content. So, if your site provides different content for different users, such as personal data, then you will not be able to cache everyone's data for a single user. However, sometimes you may want to ignore cookies, for example, for some analytical work. If the site does not provide any personal data, then the only place to consider cookies is the admin section-if the varnish cache the admin part, it would be inconvenient to view the changes.

Let's revise the/ETC/VARNISH/DEFAULT.VCL file. Assuming that your backend admin section is/admin, you need to add the following:

Copy Code code as follows:

Sub Vcl_recv {
if (! (req.url ~ ^/admin/)) {
Unset Req.http.Cookie;
}
}

Some cookies can be very important, such as users who are already logged in and cookies should not be cached. So, you wouldn't want to exclude all cookies. A regular expression is used here to define the cookies that we need. can also be down oh that online find a lot of solutions to this problem. For cookies for analysis tools, you can add the following:

Copy Code code as follows:

Sub Vcl_recv {
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*", "");
}

There is a special section in the varnish document explaining cookies.

In most situations, the varnish of the above configuration and the removal of cookies from the analysis tool will greatly speed up access to the site. Once the varnish is established and running, you can fine-tune the configuration and get the best performance from the cache rules, based on familiarity with the configuration.
Advanced

For more information, please refer to varnish official documentation. You should try some examples from now to get a deeper understanding of varnish basics.