Website Acceleration--cache for the Wang article

This is reproduced, not original, I this month is one, so the above selected original type. Sorry.

Http://blog.sina.com.cn/s/blog_466c66400100bi2y.html

Yang Jian: Website Acceleration--cache for Wang (2008-12-08-20:14:58)

Category: System architecture

--Improve performance while saving you more than 10 times times the cost
From:http://blog.sina.com.cn/iyangjian

One, the Cache, kingly also
Introduction to the basic principle of Cache
Three, I divided the 3 refresh levels
Four, I do a little innovation to the HTTP protocol (? maxage=6000000)
Five, YSlow optimize the performance of the Web site 14 comments
Six, on-line!= finished
Seven, lifting speed and cost-saving method summary
-----------------------------------------------------------------------------------------

One, the Cache, kingly also

I think the system architecture should not just build a strong can withstand huge concurrent pressure of the background, the front-end page is also required architecture and equally important, do not understand the foreground of the backstage engineer is unqualified. The Chinese people pay attention to steel soft phase, background tough can only say that you deep, the front-end use of Qiao, that call four or two.

General background engineers rarely care how the front-end uses their resources, and the front-end engineers do not know how much of a simple usage of their own will affect the backend. I'll give you some data to shock your eyeballs.

Two, the Cache basic principle Introduction (Reference Caching Tutorial)

Why use cache.
1, reduce latency, make your site faster, improve the user experience.
2, avoid network congestion, reduce requests, reduce output bandwidth.
Add a cache of the principle: not updated resources should not let it generate HTTP request again, if forced to produce a request, then see if it can return 304.

The type of cache.
Browser cache, agent cache, gateway cache.
The back end also has disk cache, server cache,php cache, but it does not belong to the scope of our discussion today.

How the cache works.
1, if the response header tells cache not to buffer it, cache does not buffer it;
2, if the request needs to be validated or required security, it will not be cached;
3, if there are no ETag or last-modifed header elements in the response, and no explicit information tells you how to keep the data fresh, it is considered not cacheable.
4, in the following cases, a cache entry is considered to be fresh (that is, it can be sent directly to the client without checking on the original server):
It sets an expiration time or age-controlling response header, and it is still not expired.
If there is a data item in the cache of the browser, and is set to check only once for each session process;
If a proxy cache can find a data item, and it has been updated over a relatively long period of time.
The above situation will think that the data is fresh, go directly to the cache, no longer query source server.
5, if one expires, it will let the original server update it, or tell the cache whether the copy is still available.

How to control your cache.
Meta Tags: specified in the HTML page, this method is only supported by a few browsers, proxy generally will not read the specific content of your HTML and then do the cache decision.

Pragma:no-cache: Commonly misused in the HTTP response header, this does not produce any effect. And actually it should only be used in the request header. However, Google's server:gfe/1.3 response to this use, it is also misused by others.

Date: Current host GMT time.

Last-modified: File update GMT time, I in the response head with this element, usually the browser in the cache time to send a request will be slightly with if-modified-since, let us judge the need to retransmit file content, Or just return a 304 to tell the browser resources have not been updated, the server needs caching policy must be supported. With this request, the head request does not have much use at all, unless it can be used on Telnet.

If-modified-since: In the request, see last-modified.

Etag: Identify whether the resources have changed, Etag generation algorithms are all kinds, usually with the inode+size+lastmodified of the file after the hash, you can choose according to the application of their own. Last-modified can only be accurate to the second update, if a number of times in a second to update, ETag can be useful. It seems that we rarely have such a precise demand, the number of bytes of HTTP header is wasted, it is recommended not to use.
Correction: Etag In some cases can be a good way to reduce data transmission. In the Stonehuang of the reminder I just suddenly realized that the blink of an eye for several months has also been forgotten to update. ETag application Scenarios. For example, the data is the dynamic output of PHP. Each request brings the last etag, compared to the etag of this calculation, the equivalent can avoid a data transfer. (Last modified 2009.12.07)

Expires: Specifies the absolute time of the cache expiration GMT, which is available in HTTP 1.0. This element has some drawbacks, one, the server and browser-side time is inconsistent with the problem. If you forget to reset the new expiration time after the expiration, the cache will fail. Third, the server side needs to be based on the current date time + cache relative time to calculate this value, requires CPU overhead. I do not recommend use.

Cache-control:
This is a new addition to the HTTP 1.1 to make up for the Expires flaw, and now browsers that do not support HTTP 1.1 are already scarce.
Max-age: Specifies the relative time seconds of cache expiration, max-ag=0 or negative, the browser will set the expires to 1970-01-01 08:00:00 in the corresponding cache, although the semantics is not transparent, but it is the most recommended.
S-maxage: Similar to Max-age, used only on shared caching, such as proxy.
Public: In general, HTTP authentication is required, and the response is not CAHCE, plus public can make it cache.
No-cache: Forces the browser to submit an HTTP request to the source server for confirmation before using the cache copy. This is very useful for authentication and can be better observed (can be considered in conjunction with public). It is also useful for maintaining a resource that is always up to date, while not completely losing the benefit of the cache because it is locally copied, but is validated before use, so that HTTP requests do not decrease, but may reduce a response body.
No-store: Tell the browser not to cache in any case, not to keep the copy locally.
Must-revalidate: Force the browser to strictly follow the cache rules you set.
Proxy-revalidate: Force proxy to strictly follow the cache rules you set.
Usage examples: cache-control:max-age=3600, must-revalidate

Other things you need to pay attention to with the cache, do not use post, do not use SSL, because they can not be cache, in addition to keep the URL consistent. Cookies are used only where necessary, usually on dynamic pages, because Coolie is difficult to cache. As for Apache how to support cache and PHP how to use the header function set cache, temporarily do not introduce, online data more.

How to set a reasonable cache time.
http://image2.sinajs.cn/newchart/min/n/sz000609.gif?1230015976759
Take my time-sharing chart For example, we need to update the frequency is 1 minutes. But in order to get the latest resources every time, we add a random number in the back, and the number of times in the same second refresh will change. Although our JS can be very good control, only one-minute request, but if the user click the Refresh button. Such calls are completely cache-independent, not even the chance to return 304.

Just imagine, if a lot of people go out through the same agent, then all the requests will penetrate the agent, can not be blocked by network management. If we do only a second cache, the direct access to the source server does not have much impact on the user, but for the proxy server, his request may be reduced from 10000 req/min to Req/min, which is 160 times times.

For our market picture such a situation, the refresh rate is 1 minutes, the better way is to change the random number (num) to num=t-t%60, where T is the current timestamp, so that you brush the URL in a minute is unchanged, the next minute will increase by 1, will again produce a new request. And my max-age is set to default 59 seconds, even if set 120 seconds actually have no effect. You might say that if you catch the tipping point, you may not get the latest data, in fact, for users, with that changeable and I this minute of the number of minutes, see the effect is the same below I give you analysis: If the user opened our time page, the current number for him is new, So he will get a current picture, and then he click the Refresh button, the user will produce HTTP request, even if the URL has not changed, the server has the latest picture will certainly return, otherwise return 304, a minute later JS refresh picture, the number of minutes plus 1, will get new resources. Does this have to do with the change in the number of times the effect is different. Are getting the latest data, but they also benefit from the cache and reduce the pressure on the back end.

Three, I divided the 3 refresh levels

The noun explains the new request: The URL has changed, and the browser will take him as a new resource (launching a new request without if-modified-since).

Correction: In Firefox later version of this has been improved, tend to use more cache, once visited will try to If-modified-since head. These performances are consistent with IE. The modified part is marked in red. (Last modified 2009.12.07)

Note: sports.sinajs.cn in IE under the performance of a small bug, because not the use of strncpy, resulting in IE difficult to return 304,
You need to modify one line of code and set the comparison string length to 29 to resolve. At present, however, I am no longer in the position to revise.
Situation one FF incidentally head: If-modified-since Mon, Modified DEC 2009 10:54:43 GMT
Situation two IE incidentally head: If-modified-since Mon, Modified DEC 2009 10:54:43 GMT; Length=6

1, enter the http://sports.sinajs.cn/today.js?maxage=11 address in the Address bar and press ENTER. Repeat n times, until the cache time 11 seconds past, before initiating the request, this request will take if-modified-since.

2, press F5 to refresh. After you initiate a new request, and then press F5 multiple times, a request with if-modified-since will be generated.

3, CTRL+F5, will always launch a new request.

The following is a F5 Refresh example demo: http://sports.sinajs.cn/today.js?maxage=11
(If this value is greater than the browser maximum cache time MaxAge, the browser will be the largest cache)

----------------------------------------------------------initiate a new request
Get/today.js?maxage=11 http/1.1
Host:sports.sinajs.cn
Connection:keep-alive

http/1.x OK
Server:cloudia
Last-modified:mon, Nov 2008 11:03:02 GMT
cache-control:max-age=11 (Browser will cache this page content, and then the cache expiration time set to the current time + 11 seconds)
content-length:312
Connection:keep-alive
----------------------------------------------------------Press F5 to refresh
Get/today.js?maxage=11 http/1.1
Host:sports.sinajs.cn
Connection:keep-alive
If-modified-since:mon, Nov 2008 11:03:02 GMT (press F5 Refresh, if-modified-since bring over last-modified time of last server)
Cache-control:max-age=0

http/1.x 304 Not Modified
Server:cloudia
Connection:keep-alive
Cache-control:max-age=11 (this max-age is somewhat superfluous, the browser discovers not Modified, will use local cache data, but will not reset local expiration time)
----------------------------------------------------------
Continue pressing F5 to refresh n times ....

The HTTP request was not generated in these 11 seconds. Until 11 seconds passed .....
----------------------------------------------------------Press F5 to refresh
Get/today.js?maxage=11 http/1.1
Host:sports.sinajs.cn
Connection:keep-alive
If-modified-since:mon, Nov 2008 11:03:02 GMT (Multiple press F5 will result in a request with if-modified-since)
Cache-control:max-age=0

http/1.x 304 Not Modified
Server:cloudia
Connection:keep-alive
cache-control:max-age=11
----------------------------------------------------------Press F5 to refresh
Get/today.js?maxage=11 http/1.1
Host:sports.sinajs.cn
Connection:keep-alive
If-modified-since:mon, Nov 2008 11:03:02 GMT (Ibid. ... ）
Cache-control:max-age=0

http/1.x 304 Not Modified
Server:cloudia
Connection:keep-alive
cache-control:max-age=11
----------------------------------------------------------


Four, I do a little innovation to the HTTP protocol (? maxage=6000000)

See above the URL there is a maxage=xx such use, this is not a common parameter, the role is not only look so simple. He has at least several advantages:

1, you can control the Max-age value of the HTTP header.
2, allowing users to flexibly customize the exact cache time length for each resource.
3, you can represent the resource version number.

First talk about the impact on the back end:
Server implementation of the block, no longer load like mod_expires,mod_headers such an additional module, also do not have to load those rules to compare, it belongs to what directory, or what file type, should cache how much time, such operations are required overhead.

Again, the impact on the front end:
For example, the same time-sharing picture, our time-sharing page needs 1 minutes to update, and some of the first page of 3 minutes to update the good. Do not use JS control, then I cache should be set how much. With MaxAge, this personalized customization needs to be met.

In another case, we set a permanent cache for the cache, but because of the need, I have to update the picture, how to let the user access to this updated image. The same method is described in terms of Yahoo's data and all available data, changing the name of the file and referencing the new resource. I think this method is too soil, renamed, the old can not be deleted, there may be a place in use, the same resources may have to deposit two, and then modify, and have to change the name, save 3, do not use the inode as a resource. I do not do that, just to change the maxage=6000000 into maxage=6000001, the problem is solved.

The power of the maxage=6000000 (memory block consumption is reduced by 250 times times and the number of requests is reduced by 37 times times):
The sports side wants a new feature, at the beginning of the dynamic access to those data, I think that too wasteful dynamic pool resources, let them to transfer the XML file to my JS pool, in order to facilitate, they put that 84k of flash files also put together, and each user must visit. To be honest, I don't welcome this big guy because it's not compressed, and normally it should represent a 3M file. My server is only designed this way, if you send an endless amount of memory, each memory block 10k, if not with the default maxage=120 parameter. I found that because of this file, 10w connections, I consumed 10,000 blocks of memory. I wrote it myself. Application of continuous memory algorithm is also consumed CPU, a 84k file, sent once, the remaining 64k should be able to install the next, so I have the smallest memory block size to 64K. This consumes 10w Conn when consumes 1500 memory fast, although the total memory consumption is not how small, but it can be faster to get 64K of contiguous memory resources, CPU also saved. Next I let Meijun the application of the flash resources followed by maxage=6000000 (probably = 79 days, the browser end of the longest cache can achieve a good), 10w connections, only consumed less than 40 memory blocks, This means that the memory block consumption is reduced by 250 times times and the request is reduced by 37 times times. 35w+ connections, 5.67w req/s time also consumes about 100 pieces, a lot less than linear increase. That's what makes me have the urge to share the technology, and all the rest of the way.


Five, YSlow optimize the performance of the Web site 14 comments

The black part, which is closely linked to the back end, has been covered in our content and has been discussed in more depth. Blue section, 5,6,7 is related to the speed of the implementation of the page, building the front-end page should be noted. 11 is a method to avoid using. In the red section, I would highlight:

Gzip I do not recommend using, because some of the early IE support is not good, it's performance for direct access to IE no problem, with JS embedded, it can not be normal decompression. Such a user account should be around 2%. I tracked the problem for nearly one months and almost gave up using compression. Later found that I used to deflate compressed files are normal access. Instead, use deflate to solve the problem. Apache 1.x use Mod_gzip, to 2.x to switch to Cmod_deflate, do not know if it is related to this reason. In addition, for small file compression, deflate can be a lot more bytes than gzip.

Reduce DNS queries: There is also a trade-off, the general browser to create a maximum of only one domain name two connection channels. If I have a page with a lot of image.xx.com pictures, you will find that the picture from the top down a picture shows the process. This creates a queue for the browser side. We can increase the concurrency by increasing the domain name, such as Image0.xx.com, image1.xx.com, image2.xx.com,image3.xx.com and so on, but it will cause a lot of cache invalidation, it is very simple, If we add a filename to the 4 mod, we can guarantee that a picture can only be accessed through a domain name. However, I am also very opposed to a page request dozens of domain names, many domain names only one or two resources of the practice, such a time cost is not cost-effective.

In addition, I add a 15th here: Stagger the resource request time, avoid the browser side queue.
With the wide use of Ajax, dynamic refreshing everywhere, sports live in a page called me a domain name under the 6 files, 3 js,3 XML. The refresh rate is approximately two 10 seconds, two 30 seconds, and two one-time loads. Observation found that the normal response time is 7ms, but every time there will be more than 100ms, I am very strange, the server load is very light. Meijun help me to stagger the refresh time, 11 seconds, 9 seconds, 31 seconds, so the response in the probability of more than 100ms reduced several times, this is the so-called details of success or failure bar.

1. Reduce the number of HTTP requests as much as possible [content]
2. Use CDN (Content Delivery network) [Server]
3. Add Expires header (or Cache-control) [Server]
4. Gzip components [Server]
5. Put the CSS style above the page [CSS]
6. Move the script to the bottom (including inline) [JavaScript]
7. Avoid using CSS in the expression_r_r_r_rs [CSS]
8. Separate JavaScript and CSS into external files [JavaScript] [CSS]
9. Reduce DNS query [content]
10. Compress JavaScript and CSS (including inline) [JavaScript] [CSS]
11. Avoid redirecting [server]
12. Remove duplicate scripts [JavaScript]
13. Configure Entity tags (ETags) [CSS]
14. Make AJAX Cache

Six, on-line!= finished

During the Olympic Games I press 1500w~2000w connections online, designed a set of standby system, now it seems that if the user really reached this number I would be very dangerous, because some of the server introduced 32bit CentOS 5 without actual online testing, And I was simply thinking that it should have the same characteristics as CentOS 4. So the Lib library and the new version, which are not fully tested, are used with caution. Not tested in the real world, not easily concluded.

Many project teams seem to keep busy, doing new projects, moving on to new projects on line, and then turning around to fix previous bugs. If a project is online, users continue to rise, it should be considered optimized, a person access, and 100w access, small changes to the back-end impact is not comparable, should not request the resources to let it cache on the user's hard disk, user access block, you also province resources. The on-line only representative can be done, it is necessary for technicians to continuously track and optimize an important project.


Seven, lifting speed and cost-saving method summary

1, write Save the HTTP server (high load speed significantly increase, save 5~10 times server)
Tailored to a number of important servers. Or choose more efficient open source software for optimization.

2, mixed use of different services (save 1~2 Times Server)
If we only support a server 30w conn, then the remaining 75% CPU resources, 95% of memory resources, and almost all the disk resources can be deployed dynamic pool system, I think the DB to the network card outage consumption is limited, I do not need to buy a new network card.

3, for the Pure Data section to enable the new domain name (speed has been upgraded, uplink bandwidth savings of more than 1 time times)
For example, we purchased a sinajs.cn to do data services to avoid cookies and save bandwidth. Cookies not only waste server-side processing power, but also uplink data, which is usually slower than the downlink.

4, the use of long connection (speed significantly increased, saving more than twice times the bandwidth, reduce network congestion 3~ not several times)
For a one-time request for multiple resources, or in a relatively short interval for subsequent requests, the use of long connections can significantly improve the user experience, reduce network congestion, reduce the cost of the backend server to establish new connections.

5, data and rendering separation, static data and Dynamic Data separation (speed significantly increased, while saving 3 times times bandwidth)
DIV+CSS data and rendering separation, it is said that the file size can be reduced to the previous 1/3.
Separate the JS files that are referenced in the page and separate the dynamic part from the static part.

6, using the DEFLATE compression algorithm (speed significantly increased, save 3.33 times times bandwidth)
Generally, the compressed file size is less than the previous 30%.
The data separated from the above is compressed (10 times times the cumulative bandwidth savings).

7, let the user as much as possible cache your resources (speed significantly increased, save 3~50 times server resources and bandwidth resources)
The above separated CSS and infrequently changed JS data part of the cache to live the appropriate time. (Ideally, the cumulative bandwidth savings 30~500 times).

The above improvements can allow a large increase in speed at the same time, the server resources to save 5~20 times, reduce network congestion 3~ no number of times, uplink bandwidth savings of more than 1 time times, downlink bandwidth savings 30~500 times, or even more.