Seven different ways to implement caching for static content

In the business world, people often say "cash is king". However, in the technical world, we say "caching is king". From the browser to the application front-end, the application backend, the database, each layer can significantly improve the system's scalability through caching, improve the responsiveness of the system, and reduce the burden of the system.

The content on the Internet platform can be divided into two kinds: static and dynamic. Static content refers to text and images that are not changed frequently. Dynamic content refers to the changing content over time. This article mainly discusses seven different methods of static content implementation caching. 1. Implement the cache with CDN

CDN, a content distribution network, connects a group of computers through a backbone network, storing copies of customer data or content. By strategically deploying edge servers and applying a large number of technologies and algorithms on different networks, the user's request is assigned to the best response node. This optimization logic can be based on the minimum number of network jumps, the highest system availability, or the minimum number of requests. This optimization is often focused on reducing response time that can be perceived by end users, requesters, or services.

Figure 1 Explains how this approach works in a real-world environment. Assume that a Web site because the traffic is too large, decided to use CDN to solve the problem. First, a new alias is created on the domain name server to point the user's request from Www.akfpartners.com/techblog to 1107.c.cdn_vendor.net (see the DNS table in Figure 1). Second, when the user browser to the Domain Name Service query (step 1) akfpartners.com, received the returned CDN domain name (step 2), and then the CDN domain name for another round of Domain Name Service query (step 3), received returned with 1107.c.cdn_vendor.net The associated IP address (step 4), and finally, receives the request and routes it to an IP (step JTG 5–6) of the Service Web site. The content of the Web site is cached on the CDN server, and the CDN server periodically queries the source server of the website for updating.

As this example shows, the effect of using a CDN in front of a Web server is that the CDN is responsible for all requests and accesses the source server only if it needs to query for updates to the buffered content. As a result, you only need to buy a small number of low configured servers and network bandwidth, as well as a few people who maintain the infrastructure. Whether the Web page is dynamic or static, you can consider joining a CDN to form a hybrid cache. This layer cache provides the benefits of fast delivery, usually with very high availability, and the site server handles less traffic. 2. Use HTTP headers to manage caching flexibly

HTTP headers provide effective control over proxy caching, which is not visible in HTML, but is dynamically generated by a network server or code that generates pages. Controlled by server configuration or code. A typical HTTP response header might look like this:

HTTP Status code:http/1.1 OK
Date:thu, OCT 2015 20:03:38 GMT
server:apache/2.2.9 (Fedora)
x-powered- by:php/5.2.6
Expires:mon, June June 2016 05:00:00 GMT Last-modified:thu
, Oct 2015 20:03:38 GMT
cache-contro L:no-cache
vary:accept-encoding, user-agent
transfer-encoding:chunked
content-type:text/html; Charset=utf-8

The most relevant headers for caching are expires and Cache-control. The Expires Entity header field provides the response expiration information. If you want to mark the response as "never expires," the source server should send a date that is one year from the response time. In the previous example, note that the Expires header identification date is May 12, 2017 05:00gmt. If today is April 12, 2017, the requested page will expire in about one months, and the browser should fetch the data from the server at that time to refresh the content.

The Cache-control Common header field is used to define directives in the HTTP1.1 protocol defined in section 14th of RFC2616, and all caching mechanisms along the request/response chain must comply with these directives. The header can emit many instructions, including public, private, No-cache, and Max-age. If the response contains both the Expires header and the max-age instruction, the max-age instruction priority is also higher than the Expires header, even if the Expires is more restrictive. The following are the definitions of some Cache-control directives: public-responses can be handled by any cache, shared, or unshared cache. The private-response is for single users and cannot be placed by the shared cache. No-cache-must not use caching to satisfy subsequent requests before confirming with the source server. max-age-if the current value is greater than the value given at the time of the request (seconds), then the response is obsolete.

There are several ways to set up HTTP headers, including through network servers and code. The Apache2.2 configuration is set in the httpd.conf file. The Expires header requires that the Mod_expires module be added to Apache. The Expires module has three basic instructions. The first expiresactive tells the server to activate the module. The second instruction Expiresbytype sets the Expires service-specific type of object (such as pictures or text). The third instruction ExpiresDefault sets how to handle all objects of unspecified types. See the following code example:

Expiresactive on
expiresbytype image/png "Access plus 1 day"
expiresbytype image/gif "modification plus 5 hours" C2/>expiresbytype text/html "Access plus 1 month 2 hours"
expiresdefault "Access plus 1 month"

Another way to set up Expires, Cache-control, and other headers in HTTP is to implement them in your code. PHP directly uses the header () command to send the original HTTP headers. The header () command must be invoked either through HTML tags or from PHP code before any output. For a header setting, see the following PHP sample code. Other languages also have similar header setting methods.

<?php
Header ("expires:0");
Header ("last-modified:"). Gmdate ("D, D M Y h:i:s"). "GMT");
Header ("Cache-control:no-store, No-cache, must-revalidate");
Header ("Pragma:no-cache");
? >

The final topic involves adjusting the configuration of a network server to optimize its performance and scalability. Keep-alives or HTTP Persistent connections allow multiple HTTP requests to be reused for TCP connections. In http/1.1, all connections are persistent, and most network servers are allowed to remain connected by default. Depending on the Apache documentation, using connection retention can reduce the HTML page latency by 50%. The default setting for Keep-alives in the Apache httpd.conf file is open, but the default value for KeepAliveTimeout is set to 5 seconds. The advantage of a longer timeout setting is that you can handle more HTTP requests without having to establish, use, and terminate a TCP connection, and the advantage of having a shorter timeout setting is that the threads of the network server are not bundled and can continue to serve other requests. It is important to find a balance between the two depending on the application or the specific situation of the site.

There is a practical example, using AOL developed the open source of the Web Test tool webpagetest.org, a site to do a test. The test object is a simple MediaWiki that runs on the 2.2 version of the Apache HTTP server.

Figure 2 shows the results of testing the Wiki page without setting the Expires header while closing the keep-alives. The page initial load time is 3.8 seconds and the repeat browsing time is 2.3 seconds.

Figure 3 shows the results of testing the Wiki page when Keep-alives is turned on and the Expires header is set. The initial load time for the page is 2.6 seconds, and the repeat browsing time is 1.4 seconds. This reduces the page initial load time by 32% and the 37% repeat page load time. 3. Using Ajax to implement caching

The term Ajax was created in 2005 by Jessi James Gallette in his article Ajax: A new method of Web application. Ajax is the abbreviation for asynchronous JavaScript and XML. While we often use it as a technique, a more appropriate description is a set of techniques, languages, and methods used on browsers (or clients) to help bring richer content and a more real-time experience to end users.

Because the data can be reduced unnecessarily on the network, so that the interaction between the user and the browser easier, so that user interaction can occur more quickly. Users can zoom in or out of a picture without waiting for a response from the server, and the Pull-down menu can be scheduled according to previous input, and when users enter query keywords in the search field, they can begin to see potential search terms that may be of interest and lead. Ajax asynchronous features can also help us, when loading mail to the client browser, depending on the user's actions to determine whether to continue to receive mail, without having to wait for the user to click the "Next Page" button.

But some of these actions are not conducive to the expansion of the platform, the user on the site to enter a specific product search keyword for example. We may want to use the catalog to populate our search suggestions, which are the keywords that appear when the user types the search criteria. Ajax can send a request to the server through each subsequent keystroke of the user, return the search results based on the words that have been typed, and populate the Drop-down menu with the search results without requiring user intervention to refresh the browser. It is possible to return a full search result based on a string that is not fully typed by the user. Many search engines and E-commerce sites can find examples of such implementations. Based on each subsequent key to ultimately form the search server needs of the query statement, may be both expensive and waste our backend system resources. For example, when a user enters "beanie Baby", it can bring in 11 consecutive searches, actually only one time. The user experience can be fascinating, but if the user presses quickly, up to 8-10 searches in fact may never have a chance to return the result before the word is finished.

Our goal is to reduce the transmission of data back and forth across the network to reduce user-perceived response times and reduce server load. Therefore, the Expires setting in the response header should be valid for a long period of time, so that the browser caches the results of the first query locally and uses them repeatedly in subsequent requests. Static or semi static objects, such as company trademarks or profile pictures, should be valid for a few days or longer. Some objects may have a strong time sensitivity, such as reading a friend's status update. In these cases, the Expires header should be set for a number of seconds or even minutes to give the user a sense of real time, while reducing the overall load.

Data sets are static or even semi dynamic (for example, a limited or context-sensitive product catalog) that is easy to solve. From the client's perspective, these results are obtained asynchronously, and then cached for later use by the same client, or, more importantly, to ensure that the CDN, intermediate cache, or proxy stores them for similar searches by other users.

Here's a bad Ajax invocation case and a better response case. A less-than-good invocation case might look like this:

HTTP Status code:http/1.1 OK
Date:thu, OCT 2015 20:03:38 GMT
server:apache/2.2.9 (Fedora)
x-powered- by:php/5.2.6
Expires:mon, June June 1997 05:00:00 GMT Last-modified:thu
, Oct 2015 20:03:38 GMT
pragma:no-c Ache
vary:accept-encoding,user-agent
transfer-encoding:chunked
content-type:text/html; charset= UTF-8

From the above information can be found Expires head occurred in the past, completely lost Cache-control head, last-modified Head and response time to send the same. These settings force all GETs to crawl new content. A better way to cache Ajax results is this:

HTTP Status code:http/1.1 OK
Date:thu, OCT 2015 20:03:38 GMT
server:apache/2.2.9 (Fedora)
X-powere d-by:php/5.2.6
Expires:sun, June June 2020 05:00:00 GMT Last-modified:thu
, Dec 1970 20:03:38 GMT
cache-c Ontrol:public
pragma:no-cache
vary:accept-encoding,user-agent
transfer-encoding:chunked
content-type:text/html; Charset=utf-8

In this case, the Expires header is set to the distant future, the last-modified head is set to the vicissitudes of the past, and through the Cache-control:public tells the intermediary agent, they can cache and reuse objects in other systems. 4. Use page Caching

Page caching is a cache server that is deployed in front of a network server to reduce requests for these servers by static and dynamic objects. Other common names for such systems or servers are reverse proxy caching, reverse proxy servers, and reverse proxies. We specifically use the term page caching because the proxy is also responsible for load balancing or SSL acceleration, and the implementation of the proxy cache looks like Figure 4.

The page cache handles some or all of the requests until the stored page or data is obsolete, or the server queries the data that the user requested. A request failure is referred to as a cache loss, possibly a cache pool full of no space to store the most recent request or cache pool dissatisfaction but the request rate is low or has recently been restarted. Cache loss is passed to the network server, which answers the request and populates the cache, either updating the least recently used record or filling an unused free space.

We have emphasized three points. First, a page cache or reverse proxy is implemented in front of the network server, which can be significantly extended. The workload of the network server generating dynamic content is greatly reduced because the results are cached within the appropriate time. Network servers that service static content do not need to find content, so reduce the number of servers. However, we think that the benefits of static page caching are not as big as dynamic content.

Second, the appropriate HTTP headers need to be used to ensure that the maximum potential (and also the appropriate business) role for content caching and result caching is played. For this reason, please refer to the previous brief discussion of Cache-control,last-modified and Expires. RFC2616 the 14th section has a complete description of these header files, related parameters and their expected results.

The 3rd is to include as many additional HTTP headers in the RFC2616 as possible, which helps to maximize content caching. This new head is called ETag. The purpose of defining ETAG or entity tags is to facilitate the If-none-match method in which the user has conditional get requests to the server. ETags is the unique identification that the server emits for the object when the browser first requests it. If the server's resources change, a new ETag is assigned. If the browser (client) provides the appropriate support, the object and its ETag are cached by the browser, and the If-none-match request from subsequent browsers to the network server will contain this label. If the label matches, the server returns a HTTP304 response with no modified content. If the label is inconsistent with the server, the server will issue the updated object and its corresponding ETag. 5. Using the application cache

To be effective in the long run, caching must be based on a system architecture perspective. For platform architecture we can benefit from the data caching capabilities of the service request by splitting the function on the service or resource (Y-axis split), or by breaking the Z-axis of some attributes of the requester or customer. The question is what kind of split would get the best benefit. As new features or new features are developed to generate new data requirements, the answer to this question may change over time. The method of implementation also needs to change over time to meet the changing needs of the business. Continuous analysis of production flow, cost per transaction, and user-perceived response time are needed to identify early indications of bottlenecks in the production environment and to deliver the data to the team responsible for the architecture.

The key question to answer is what type of split (or further subdivision) can derive maximum benefit from the scalability and cost perspective. With the appropriate split and the data caching capabilities brought to the application server, it is entirely possible to handle the current production system twice times, three times times, or even 10 times times the flow with fewer production servers. For example, the electric business website has many functions, including search, browsing, picture checking (including scaling), account updating, login, shopping cart, checkout, suggestion, etc. Current production flow analysis shows that 80% of the transactions are focused on the use of search, browsing and referral products and several other functions, and focus on less than 20% of the inventory. We can use the 80-20 rule to split these services, using a relatively small percentage of the target's high hit rate compared to the entire user base. Caching can be high, and dynamic systems can benefit from similar early-request delivery results.

Perhaps we will also find some advanced users who are making frequent requests. For these specific user functions, we may decide to enforce the split by user properties for user-specific features such as logins, shopping carts, account updates (or other account information). Another example is the assumption that we operate a SaaS business that supports corporate customer support through managed telephony, e-mail, chat, and relationship management systems. In a system, there are a large number of rules related to a particular business. On a per-business basis, a large amount of memory may be required to cache these rules and the data required for some business operations. If you come to the conclusion that customer-oriented split is the right path, then congratulations.

The last example involves social networks or interactive websites. You may guess that we will apply the 80-20 principle again and rely on the information of the production environment to help us make the decision. Social networking often involves a small amount of incredibly large share traffic. These users are sometimes active consumers, sometimes active producers (other people's destinations), and sometimes both. First determine if there is a small amount of information or a subweb with a "read" flow exceeding the normal proportions. Such nodes in social networks are instructive to our architectural considerations, and can lead us to the Z-axis splitting of these producers so that their node activity is highly cacheable from the read perspective. Assuming the 80-20 principle is correct, a few servers now serve nearly 80% of the read traffic.

In social networks, what happens to producers who are very active in content or updates. The answer may vary depending on whether the content has a high consumption rate (read) or mostly dormant. When the user has high productivity (write/update) and higher consumption (read) rate, we can directly publish content to the lane or node being read. If the read-write conflict causes "node" heat to start to become a problem, then we can use read replication and horizontal extension techniques to solve. 6. Use Object caching

Object caching is a data store (usually in memory) that is used to store a hash digest for each object. These caches are primarily used to store data that may require large computational resources to be available for retrieval, such as the result set of a complex query for a database. The hash function converts a large number of variable lengths into a small hash value. This hash value (also known as hash and/or checksum) is usually an integer that can be used as an index in an array.

# echo ' AKF ' | md5sum
90c9e7fd09d67219b15e730402d092eb[em][em]-
# echo ' Hyper growth Scalability
AKF faa216d21d711b81dfcddf3631cbe1ef[em][em]-

There are many different kinds of object caching, such as popular redis,memcached, Apache OJB and Ncache, and countless. The way of implementation is more than the diversity of tool choices. Object caching is typically deployed between databases and applications to cache SQL query result sets. However, some people use object caching for the results of complex application calculations, such as user referrals, product priorities, or ad reordering based on recent performance. The most common implementation is to put object caching in front of the database layer, because it is usually the most difficult and expensive to expand the database, while the implementation of object caching is the human path.

In addition to the CPU and memory usage of the database, the SQL query list is the most representative indicator that the system needs target caching. The list of SQL queries is the generic term for reports generated by the most frequent and resource-intensive queries that are run on the database. Oracle's Enterprise Manager Grid control has a built-in SQL query assessment tool to identify the most densely populated statements of SQL resources. This data can also be used to show which queries can be eliminated from the database by adding a cache, in addition to identifying slow queries and scheduling improvements to their work priorities. All common databases have similar reports or tools that provide services through built-in or additional tools.

Once you have decided to implement the object cache, you need to select the most appropriate scenario. Remind those technical teams who might consider building their own solutions. There are too many production-level object caching schemes to choose from. For example, Facebook uses more than 800 servers to provide more than 28TB of memory for its systems. Although you may make a decision to build instead of buy or use an Open-source object cache, this decision needs to be considered in detail.

The next step is to implement the object cache, which is usually straightforward. Memcached supports clients in many different programming languages, such as Java, Python, and PHP. PHP has get and set two basic commands. We can see from the example below that we are connected to the memcached server. If the connection fails, the Dbquery function is used to query the database, which is not shown in the example. If the Memcached connection succeeds, an attempt is made to retrieve data associated with a particular key. If get fails, we query db and deposit the $data into Memcached so that we can expect to find it in the cache the next time we query. The false identity in the SET command is used for compression, and 90 is the cache expiration in seconds.

$memcache = new Memcache;
If ($memcache->connect (' 127.0.0.1 ', 11211)) {
[em][em]if ($data = $memcache->get (' $key ')] {
[em]} else { C3/>[em][em][em][em] $data = Dbquery ($key);
[EM] [EM] [EM] [em] $memcache->set (' $key ', $data, false,);
[EM] [EM]}
} else {
[em][em] $data = Dbquery ($key);
}

The final step in implementing object caching is to monitor cache hit rates. This is the rate at which the requested object can be found in the cache system and the total number of requests. Ideally, the ratio should be 85% or higher, meaning that the request object is not cached or the cache object expires with only 15% or fewer opportunities. If the cache hit rate drops, you need to consider adding more object caching servers. 7. Standalone Object Caching

Many companies start implementing object caching from a network or application server. Such implementations are simple and effective, and object caching can be achieved without having to invest in additional hardware or cloud platform virtual machines. The disadvantage is that the object cache consumes a large amount of memory on the server, resulting in an object cache that cannot be extended independently of the application or network layer.

A better option is to configure the object cache on your own tier of servers. If you use object caching to store query result sets, you will deploy between the application server and the database. If the cache object is created at the application level, then the object caching layer is deployed between the network and the application server. See the schema diagram in Figure 5. This is the logical schema, where the object cache layer may be a physical server for caching database objects and application objects.

The advantage of separating these layers is that the server can be appropriately selected based on the memory and CPU requirements. In addition, servers in the object cache pool can be extended independently of other server pools. Properly evaluating a server can save a lot of money because object caching typically requires a large amount of memory, storing objects and keys in memory, but requiring relatively low computational power. You do not have to split the application or the network server, add the server if necessary, and allow the object cache to use additional capacity.

Recommended reading:

Architecture Canon: The design principles of the Internet Technology Architecture (2nd edition of the original book)
Author: Martin L. Abbott, Michael T. Fisher