Local cache analysis for ASP.NET performance optimization
- 2020-05-16 06:39:34
- OfStack
In the process of website development, a common requirement scenario is:
1. The page contains hot news, which needs to be updated once in 10 minutes, while the rest of the page will not change within 1 day;
2: some BANNER on the home page needs to be explicit: welcome ***;
In scenario 1 above, if the entire page is caches for 10 minutes, there is a performance overhead, so the best strategy is to use different caches for different parts of the page. For scenario 2 as well as scenario 1, we should not make the entire page uncacheable in order to accommodate the fact that some BANNER cannot apply caching.
It is fair to say that if our caching strategy during the development of the web site does not support page local caching, the overall architecture is unreasonable.
1: local caching common solutions
For the above requirements, there are several types of solutions:
1. Client Side Includes(CSI) : the content of another page is dynamically included through frame, iframe, javascript, javacript+ajax, etc. javascript libraries like the popular jquery library have good support for this.
Advantages: can use the browser client side parallel processing and loading mechanism; The browser caching mechanism can reduce the network transmission time and improve the performance. The computation is placed on the client side to reduce the pressure on the server side
Disadvantages: search engine optimization problems; javascript compatibility issues; The client side cache may cause the server side content update can not take effect in time; Security risks such as XSS
2. Server Side Includes(SSI) :
Advantages: SSI technology is a general technology, not subject to specific language restrictions, only need Web server or application server support, Ngnix, Apache, Tomcat, Jboss and so on have good support
Disadvantages: SSI does not have the syntax to directly include other servers' url (although it can also be implemented flexibly through redirect, etc.), so it is relatively inflexible in an environment that requires full use of caching and load balancing.
Of course, if you do not use a separate cache server, but use Ngnix, Ngnix for SSI and Memcached support, NginxHttpSsiModule, NginxHttpMemcachedModule can also achieve page caching, but compared with professional cache servers (such as Varnish), Ngnix as a cache server is only suitable for small and medium-sized occasions.
3. Use ASP.NET fragment cache
You can use user controls to segment the page and write cached statements in the ascx file instead of the aspx file, so that ASP.NET can cache only the output of the ascx fragment.
Disadvantages: fragment caching does not support Location features; The only valid place to cache a page fragment is the web server. This is because fragment caching is a new feature in ASP.NET, so browsers and proxy servers do not support it. Since it is not the W3C standard, proxy servers such as SQUID and VARNISH do not support it.
4. Edge Side Includes (ESI) :
Edge Side Includes(ESI) and Server Side Includes(SSI) have similar functions. SSI requires a special file suffix (shtml,inc). ESI can include remote server files directly through URI, and ESI is better suited for caching entire pages or page fragments on a caching server, so ESI is especially suited for caching. This article describes the ESI approach to local caching.
Advantages: ESI is a standard of W3C, which is supported by the popular cache servers SQUID and Varnish.
2: ESI ASP.NET implementation
This article describes the implementation of ESI local caching. Main page (test1.aspx) front desk:
The background of the main page, please refer to the previous article, adopts the caching strategy for the main page, that is, using the esi:include logo in the page.
The foreground of the included page (test2.aspx) :
The background of the included page does not need to deal with anything, that is, no caching policy is added to it, and the page is real-time.
The VARNISH configuration file is as follows:
In the vcl_fetch function above, two judgments are added, which means that if test1.aspx is encountered, esi will be processed; if test2.aspx is encountered, IIS will be ignored and the background IIS will be processed.
Note that the -p option has been added to the launch command (this is a small problem of 1 varnish, please refer to it, not listed here) :
varnishd -a :8011 -T :8088 -f c:/varnish/etc/default.vcl -p esi_syntax=0x1 -s file,c:/varnish/var/cache,100M
Effect of 3:
After starting varnish, we found that for test2.aspx, since we used esi to include it, and test2.aspx was not cached, the content of test1.aspx did not change during the cache validity period of test1.aspx with every refresh, but the region containing test2.aspx will be refreshed in real time.
Reference (section 1 is mostly from reference text) :
https://www.varnish-cache.org/trac/ticket/352
1. The page contains hot news, which needs to be updated once in 10 minutes, while the rest of the page will not change within 1 day;
2: some BANNER on the home page needs to be explicit: welcome ***;
In scenario 1 above, if the entire page is caches for 10 minutes, there is a performance overhead, so the best strategy is to use different caches for different parts of the page. For scenario 2 as well as scenario 1, we should not make the entire page uncacheable in order to accommodate the fact that some BANNER cannot apply caching.
It is fair to say that if our caching strategy during the development of the web site does not support page local caching, the overall architecture is unreasonable.
1: local caching common solutions
For the above requirements, there are several types of solutions:
1. Client Side Includes(CSI) : the content of another page is dynamically included through frame, iframe, javascript, javacript+ajax, etc. javascript libraries like the popular jquery library have good support for this.
Advantages: can use the browser client side parallel processing and loading mechanism; The browser caching mechanism can reduce the network transmission time and improve the performance. The computation is placed on the client side to reduce the pressure on the server side
Disadvantages: search engine optimization problems; javascript compatibility issues; The client side cache may cause the server side content update can not take effect in time; Security risks such as XSS
2. Server Side Includes(SSI) :
Advantages: SSI technology is a general technology, not subject to specific language restrictions, only need Web server or application server support, Ngnix, Apache, Tomcat, Jboss and so on have good support
Disadvantages: SSI does not have the syntax to directly include other servers' url (although it can also be implemented flexibly through redirect, etc.), so it is relatively inflexible in an environment that requires full use of caching and load balancing.
Of course, if you do not use a separate cache server, but use Ngnix, Ngnix for SSI and Memcached support, NginxHttpSsiModule, NginxHttpMemcachedModule can also achieve page caching, but compared with professional cache servers (such as Varnish), Ngnix as a cache server is only suitable for small and medium-sized occasions.
3. Use ASP.NET fragment cache
You can use user controls to segment the page and write cached statements in the ascx file instead of the aspx file, so that ASP.NET can cache only the output of the ascx fragment.
Disadvantages: fragment caching does not support Location features; The only valid place to cache a page fragment is the web server. This is because fragment caching is a new feature in ASP.NET, so browsers and proxy servers do not support it. Since it is not the W3C standard, proxy servers such as SQUID and VARNISH do not support it.
4. Edge Side Includes (ESI) :
Edge Side Includes(ESI) and Server Side Includes(SSI) have similar functions. SSI requires a special file suffix (shtml,inc). ESI can include remote server files directly through URI, and ESI is better suited for caching entire pages or page fragments on a caching server, so ESI is especially suited for caching. This article describes the ESI approach to local caching.
Advantages: ESI is a standard of W3C, which is supported by the popular cache servers SQUID and Varnish.
2: ESI ASP.NET implementation
This article describes the implementation of ESI local caching. Main page (test1.aspx) front desk:
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="test1.aspx.cs" Inherits="WebApplication2.aspx.test1" %>
<%@ Import Namespace="System.Globalization" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
</head>
<body>
<div> This is the local cache </div>
<esi:include src="test2.aspx"/>
<div> Local cache end </div>
<%=DateTime.Now.ToString("U", DateTimeFormatInfo.InvariantInfo)%>
</body>
</html>
The background of the main page, please refer to the previous article, adopts the caching strategy for the main page, that is, using the esi:include logo in the page.
The foreground of the included page (test2.aspx) :
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="test2.aspx.cs" Inherits="WebApplication2.aspx.test2" %>
<%@ Import Namespace="System.Globalization" %>
<div>
Page in local cache:
<%=DateTime.Now.ToString("U", DateTimeFormatInfo.InvariantInfo)%>
</div>
The background of the included page does not need to deal with anything, that is, no caching policy is added to it, and the page is real-time.
The VARNISH configuration file is as follows:
backend default {
.host = "192.168.0.77";
.port = "80";
}
sub vcl_fetch {
remove beresp.http.Set-Cookie;
if(req.url ~ "test1.aspx") {
esi;
}
if(req.url ~ "test2.aspx"){
return (pass);
}
}
sub vcl_recv {
remove req.http.Cookie;
#remove req.http.Accept-Encoding;
#remove req.http.Vary;
}
sub vcl_hit {
if(req.http.Cache-Control~"no-cache"||req.http.Cache-Control~"max-age=0"||req.http.Pragma~"no-cache"){
set obj.ttl=0s;
return (restart);
}
return (deliver);
}
sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT";
} else {
set resp.http.X-Cache = "MISS";
}
}
In the vcl_fetch function above, two judgments are added, which means that if test1.aspx is encountered, esi will be processed; if test2.aspx is encountered, IIS will be ignored and the background IIS will be processed.
Note that the -p option has been added to the launch command (this is a small problem of 1 varnish, please refer to it, not listed here) :
varnishd -a :8011 -T :8088 -f c:/varnish/etc/default.vcl -p esi_syntax=0x1 -s file,c:/varnish/var/cache,100M
Effect of 3:
After starting varnish, we found that for test2.aspx, since we used esi to include it, and test2.aspx was not cached, the content of test1.aspx did not change during the cache validity period of test1.aspx with every refresh, but the region containing test2.aspx will be refreshed in real time.
Reference (section 1 is mostly from reference text) :
https://www.varnish-cache.org/trac/ticket/352
http://cd34.com/blog/infrastructure/no-esi-processing-first-char-not/
http://hi.baidu.com/chuanliang2007/blog/item/075f67963e20f315d31b7035.html
http://www.w3.org/TR/esi-lang