Ybsoftwarefactory code Generation Plug-in "21": Several tips for Web API and MVC performance improvement

Recently in the process of ybsoftwarefactory upgrade, has been basically completed, and now will use some of the Web Api and MVC performance improvement of some of the tips to summarize, these techniques in use, configuration is quite simple, but usually can greatly improve the performance of the application, Hope to be useful to everyone.

First, the cache

In order to avoid each request to access the background resources, we generally consider some of the updates are not very frequent, can be reused data, through a certain way to temporarily save, and subsequent requests according to the situation can directly access these saved data, this mechanism is called caching mechanism. The cache is divided into page output cache, memory data cache, cache dependency and so on. From the design principle, the volatile, sensitive information is not suitable for caching, while the content of the cache is also easy to lose, in the code can not be completely dependent on the cached data, it is necessary to ensure that the cached data is lost after the correct processing.

1. Page Output Cache

By caching the output page, each time a new user request invokes the same Action, the same content does not need to be recreated and is output directly. The use of the page output cache is simple , and it takes effect with the [OutputCache] attribute tag on the Action. The page output cache controls where cached content is stored, such as whether the cached page content is stored on the server side or the cached page content stored on the client, or you can use the Duration parameter to control the cache's expiration absolute time and interval, or even to use VaryByParam The parameters are cached separately for different request parameters. The page output cache is well suited for caching content-relatively fixed front-end pages.

2. Memory Data Cache

Typically, data is stored on storage media such as databases, disk files, and applications accessing these resources is a time-consuming operation. If you first cache the data in these resources into memory buffers, you can reduce system overhead by extracting the data directly from the buffer when the application needs it , which significantly increases the number of user concurrency that can be used. The in-memory data cache takes into account how cached content changes fail to clear other data issues that are associated with the cache.

3, Efcache

As we all know, Nhiberate provides a level two cache feature. Now, if you are using the Entity Framework 6 or later, you can also consider using the Efcache component to provide level two cache support for the Entity Framework, which is essentially a memory data cache. Efcache is characterized by its ease of use and the need to define code as follows to achieve level two caching without additional complex additional configuration. If you need to define a specific cache policy, such as the expiration time of the cache, control the scope of the data cache, you only need to inherit the Cachingpolicy class and override some of its methods. You can even implement a custom cache model by implementing the ICache interface to replace the default Inmemorycache.

After testing, using Efcache, the usual performance improvements are obvious. The reference code is as follows:

1     /// <summary>2     ///EF Level Two cache configuration, such as no level two cache please note the following class definition3     /// </summary>4      Public classconfiguration:dbconfiguration5     {6         Private StaticInmemorycache _cache =NewInmemorycache ();7          PublicConfiguration ()8         {9             varTransactionhandler =NewCachetransactionhandler (_cache);Ten  One Addinterceptor (transactionhandler); A  -             varCachingpolicy =NewCachingpolicy (); -  theLoaded + = -(sender, args) = args. Replaceservice<dbproviderservices>( -(S, _) = =NewCachingproviderservices (S, Transactionhandler, - cachingpolicy)); +         } -          Public Static voidClearCache () +         { A _cache. Purge (); at         } -}

Second, stream compression

The function of compressing the response stream is to reduce the network overhead and improve the response speed of the system. The current browser usually supports gzip and deflate compression decompression, so you usually do not consider browser compatibility issues. Enabling gzip and deflate can be implemented through the IIS configuration, or in MVC by writing a custom Actionfilter implementation. The difference in the size of the Stream before and after compression is usually staggering, and its compression rate is usually more than 5-10 times.

You can look at the following monitoring data:

Third, JS and CSS file compression and packaging

1, JS and CSS file compression

The essence is to generate smaller files, reduce the network overhead of downloading these files, and provide a system response speed. One of the benefits of compressing JS and CSS files is that you can often play a role in code obfuscation. In the Ybsoftwarefactory MVC solution, the Microsoft Ajax minifier component is used to automatically compress the configured JS and CSS during code compilation, and the file size can be reduced by more than half:

In Ybsoftwarefactory's MVC solution, conditional compilation symbols are used skillfully, the uncompressed version can be used in debug mode for debugging purposes, and in Release mode it is automatically switched to a reference to a compressed file and via the Microsoft Ajax Mi Nifier generates the latest compressed version of the file, which is very convenient for program development and deployment, such as the following code:

1 @{2Viewbag.title ="Product";3Viewbag.allowedit =true;4Viewbag.adminjsurl =YbRapidSolution.Mvc.AutofacBootStrapper.RELEASE5? @Url. Content ("~/scripts/admin/products/index.min.js")6: @Url. Content ("~/scripts/admin/products/index.js");7     varCommonJs =YbRapidSolution.Mvc.AutofacBootStrapper.RELEASE8? @Url. Content ("~/scripts/admin/products/_common.min.js")9: @Url. Content ("~/scripts/admin/products/_common.js"); Ten}

2, JS, css file packaging

The purpose is to do a combination of JS files and CSS files, the current mainstream browser of the number of concurrent connections is usually 6 by default, if the front-end page simultaneously requests server resources (such as IMG files, JS files, CSS files and various types of URL requests, etc.) more than 6, usually need to queue download. The combination of JS files, CSS files, usually can be completed in one request before the packaging required multiple requests to complete the work, by reducing the front-end browser connection request, in a sense can also improve the system's response speed. The packaging of JS, CSS files can often use MVC's own Bundle function, but also can use some special packaging tools, specifically no longer described in detail.

For more information, click: Permissions model + process expert Demo

Attached: ybsoftwarefactory Operating Manual

Annex II: Ybsoftwarefactory bottom Component Help documentation

Ybsoftwarefactory code Generation Plug-in "21": Several tips for Web API and MVC performance improvement