Bạn hiện đang ngoại tuyến, hãy chờ internet để kết nối lại

Những điểm mới của ASP.NET 4.5 Core runtime

Về tác giả
Bài viết này được cung cấp bởi MVP Lê Hoàng Dũng. Microsoft chân thành cảm ơn những MVP đã chia xẻ những kinh nghiệm chuyên môn của mình với những người sử dụng khác. Bài viết này sẽ được đăng trên website hoặc blog của MVP sau đây. Nếu bạn muốn xem các bài viết khác được chia xẻ bởi MVP, vui lòng nháy chuột vào đây.
Tóm tắt thông tin
1. Đọc và ghi bất đồng bộ các đối tượng HTTP Request và Response
ASP.NET 4 giới thiếu khả năng đọc một thực thể HTTP request như là một stream bằng cách sử dụng phương thức HttpRequest.GetBufferlessInputStream. Phương thức này cung cấp khả năng truy xuất stream cho thực thể request, nhưng nó được thực thi đồng bộ, và như vậy nó sẽ làm nghẽn thread vì phải thực thi việc đọc stream.

ASP.NET 4.5 hỗ trợ khả năng đọc stream bất đồng bộ trên thực thể HTTP request, và khả năng flush bất đồng bộ. ASP.NET 4.5 cũng giúp cho bạn có khả năng tăng gấp đôi buffer cho một thực thể HTTP request, điều đó giúp cho việc tích hợp dễ dàng với các các downstream HTTP handlers như là các trang .aspx và các ASP.NET MVC controllers.

1.1.Các cải tiến cho việc quản lý HttpRequest

Stream được tham chiếu bởi HttpRequest.GetBufferlessInputStream trong ASP.NET 4.5 hỗ trợ các phương thức đọc đồng bộ và bất đồng bộ. Đối tượng Stream được trả về từ phương thức GetBufferlessInputStream nay đã cài đặt cho cả hai phương thức BeginRead và EndRead. Các phương thức bất đồng bộ của Stream giúp bạn đọc bất đồng bộ thực thể Request theo từng chunks (từng phần nhỏ), trong khi đó ASP.NET sẽ giải phóng thread hiện tại đối với mỗi vòng lặp của việc đọc bất đồng bộ.

ASP.NET cũng thêm vào một phương thực mới cho việc đọc thực thể request theo cách đọc sử dụng bộ đệm là HttpRequest.GetBufferedInputStream. Phương thức nạp chồng mới này cũng giống với phương thức GetBufferlessInputStream, hỗ trợ các phương thức đọc đồng bộ lẫn bất đồng bộ. Tuy nhiên, khi GetBufferedInputStream đọc, nó sao chép tuyên các bytes của thực thể request vào trong bộ đệm nội vi của ASP.NET do đó các downstream modules và các handlers vẫn có thể truy xuất vào đối tượng request. Ví dụ, nếu một số mã upstream đang nằm trong đường ống (pipeline) đã đọc thực thể request sử dụng phương thức GetBufferedInputStream, bạn vẫn có thể sử dụng HttpRequest.Form hoặc HttpRequest.Files. Điều này giúp cho bạn có thể xử lý bất động bộ đến request (ví dụ như vừa streaming một tập tin kích thước lớn đến CSDL), nhưng mà vẫn tiếp tục chạy được các trang .aspx và controllers.

1.2 Ghi dữ liệu bất đồng bộ lên đối tượng response
Gởi các response đến trình HTTP khách có thể làm tốn kém thời gian khi client ở quá xa hoặc có kết nối băng thông hẹp. Bình thường thì ASP.NET sẽ truyền các bytes trả về sau đó gọi lệnh gởi bộ đệm nói trên vào thời điểm kết thúc xử lý request.

Nếu nội dung trả về (được buffer) là lớn (ví dụ như gởi về một tập tin lớn cho client), bạn phải lặp lại việc gọi HttpResponse.Fush để gởi về client và giữ mức sử dụng bộ nhớ nằm trong tầm kiểm soát. Tuy nhiên, Flush là một lời gọi đồng bộ, nên việc gọi đi gọi lại Flush sẽ tiêu tốn nhiều thời gian.

ASP.NET 4.5 đã có thêm sự hỗ trợ cho việc ghi dữ liệu bất đồng bộ bằng các phương thức BeginFlush và EndFlush của đối tượng HttpResponse. Sử dụng các phương thức này sẽ giúp bạn tạo được các module bất đồng bộ và các hanlder bất động bộ mà chúng sẽ gởi dữ liệu liên tục về client mà không làm chậm các thread của hệ điều hành. Giữa các lời gọi BeginFlush và EndFlush, ASP.NET giải phóng thread hiện tại. Khi sđó nó sẽ giảm bớt lượng các thread cần phải chờ hỗ trợ các lượt tải về tốn nhiều thời gian.

2. Hỗ trợ cho các các module và handler bất đồng bộ dạng await và task-based (Support for await and Task-Based Asynchronous Modules and Handlers)
Nền tảng .NET 4 đã giới thiệu đến khái niệm lập trình bất đồng bộ gọi là task. Các task được đại diễn bởi kiểu dữ liệu Task và các kiểu liên quan có trong namespace System.Threading.Tasks. Nền tảng .NET 4.5 tiếp tục cải tiến và giúp cho việc làm việc với các đối tượng Task trở nên đơn giản hơn. Với .NET 4.5, trình biên dịch hỗ trợ hai từ khóa mới đó là await và async. Từ khóa await giúp xác định một đoạn mã lệnh phải chờ đợi bất đồng bộ đến khi một đoạn code khác thực thi xong. Còn từ khóa async thì lại là chỉ dẫn rằng bạn có thể sử dụng các phương thức có từ khóa đó như là các phương thức bất đồng bộ dạng task-based.

Sự kết hợp giữa hai từ khóa await, async và đối tượng Task giúp cho bạn có thể dễ dàng viết mã bất đồng bộ trong .NET 4.5. ASP.NET 4.5 hỗ trợ bằng các APIs giúp cho bạn có thể viết các HTTP modules và các HTTP handlers bất đồng bộ sử dụng các cải tiến của trình biên dịch.


2.1. Các module HTTP bất đồng bộ
Giả sử bạn muốn thực hiện công việc bất đồng bộ với một phương thức trả về đối tượng Task. Mã ví dụ sau đây định một phương thức bất đồng bộ mà nó thực hiện một lời gọi bất đồng bộ để tải về trang nhà của Microsoft.

private asyncTask ScrapeHtmlPage(object caller, EventArgs e) {    WebClient wc = new WebClient();    var result = await wc.DownloadStringTaskAsync("http://www.microsoft.com");    // Do something with the result}
Đó là tất cả những gì bạn cần viết và nền tảng .NET sẽ tự động quản lý call stack trong khi chờ đợi việc download thực hiện xong, cũng như phục hồi call stack khi việc download hoàn thành.

Bây giờ giả như bạn muốn sử dụng phương thức bất đồng bộ trong một ASP.NET HTTP module. ASP.NET 4.5 có một phương thức trợ giúp (EventHandlerTaskAsyncHelper) và một kiểu dữ liệu delegate mới (TaskEventHandler) mà nhớ đó bạn có thể dễ dàng tích hợp các phương thức bất đồng bộ dạng task-based với mô thức lập trình bất động bộ được thực thi bởi ASP.NET pipeline. Ví dụ dưới đây cho thấy cách thực hiện:

public void Init(HttpApplication context) {   // Bọc lại phương thức dạng Task-based để có thể dùng được với   // cách thức lập trình bất đồng bộ cũ.   EventHandlerTaskAsyncHelper helper =        new EventHandlerTaskAsyncHelper(ScrapeHtmlPage);         // Đối tượng helper giúp tách dễ hai phương thức Begin/End ra khỏi        // phương thức trả về đối tượng Task. ASP.NET pipeline gọi         // các phương thức Begin và End để bắt đầu và kết thúc các lời gọi đến        // các module HTTP bất đồng bộ.        context.AddOnPostAuthorizeRequestAsync(            helper.BeginEventHandler, helper.EndEventHandler);    }
2.2. Các Http handler bất đồng bộ

Cách tiếp cận truyền thống để viết các handler bất đồng bộ trong ASP.NET chính là cài đặt interface IHttpAsyncHandler. ASP.NET 4.5 giới thiệu kiểu bất đồng bộ HttpTaskAsyncHandler mà bạn có thể kế thừa, và sẽ giúp việc xây dựng các handler bất đồng bộ dễ dàng hơn.

Kiểu HttpTaskAsyncHandler là trừu tượng và yêu cầu bạn phải quá tải phương thức ProcessRequestAsync. ASP.NET sẽ chịu trách nhiệm về việc tích hợp dấu hiệu dạng Task-based được ProcessRequestAsync với mô hình lập trình bất đồng bộ cũ được sử dụng bởi ASP.NET pipeline.

Ví dụ dưới đây chỉ dẫn cho bạn cách sử dụng Task và từ khóa await như là một phần của việc cài đặt một HTTP handler bất đồng bộ

public class MyAsyncHandler : HttpTaskAsyncHandler{    // ...     // ASP.NET tự động quản quản lý việc tích hợp phương thức này    // với ASP.NET pipeline.    public override async Task ProcessRequestAsync(HttpContext context)    {        WebClient wc = new WebClient();        var result =             await wc.DownloadStringTaskAsync("http://www.microsoft.com");        // Do something with the result    }}
3. Các tính năng mới kiểm tra tính hợp lệ đối với Request
ASP.NET mặc định thực hiện việc kiểm tra tính hợp lệ đối với request, nó sẽ kiểm tra các request để tìm các thẻ hoặc script trong các trường, header, cookies… Nếu như nó phát hiện được điều gì bất hợp lệ, ASP.NET sẽ ném ngoại lệ. Hành vi này là tuyến phòng ngừa đầu tiên ddooois với lối tấn công cross-site scripting attack.

ASP.NET 4.5 giúp cho việc đọc các dữ liệu chưa được kiểm tra dễ dàng hơn. ASP.NET 4.5 cũng mặc định tích hợp thư viện AntiXSS.

Các lập trình viên thường yêu cầu cho phép được tuyef chọn tắt việc kiểm tra hợp lệ đối với request trong các ứng dụng của họ. Ví dụ như, nếu ứng dụng của bạn là một diễn đàn, bạn sẽ muốn cho phép người dùng gởi lên các bài viết theo định dạng HTML nhưng vẫn đảm bảo rằng việc kiểm tra tính hợp lệ sẽ được thực hiện ở những nơi còn lại.

ASP.NET 4.5 giới thiệu hai tính năng cho phép bạn dễ dàng làm việc với các dữ liệu nhập không được kiểm tra: làm chậm việc kiểm tra tính hợp lệ của request và truy xuất vào dữ liệu chưa được kiểm tra của request.

2.1 Làm chậm (“lazy”) việc kiểm tra tính hợp lệ của request
Trong ASP.NET 4.5, tất cả các dữ liệu request đều phải được kiểm tra tính hợp lệ. Tuy nhiên bạn có thể cấu hình ứng dụng cho phép hoãn kiểm tra tính hợp lệ cho đến khi bạn truy xuất xong dữ liệu của request. Bạn có thể cấu hình ứng dụng để sử dụng kiểm tra hợp lệ chậm (deferred validation) trong Web.config bằng cách gán giá trị cho thuộc tính requestValidationMode trong thẻ httpRuntime là 4.5 như dưới đây:

<httpRuntime requestValidationMode="4.5" ... />
Khi requestValidationMode được quy định là 4.5, việc kiểm tra tính hợp lệ cho request chỉ thực hiện cho từng giá trị cụ thể khi và chỉ khi mã lệnh của bạn truy xuất giá trị đó. Ví dụ như khi bạn lấy giá trị Request.Form["forum_post"], chỉ có phần tử đó được kiểm tra tính hợp lệ mà thôi. Các phần tử khác trong tập hợp Form sẽ không được kiểm tra. Trong phiên bản trước của ASP.NET, kiểm tra hợp lệ cho request sẽ được thực hiện đối với cả tập hợp Form khi có bất kỳ phần tử nào của tập hợp Form được truy xuất. Tính năng mới này giúp cho các thành phần của ứng dụng chỉ khi truy xuất phần tử nó cần sẽ không kích hoạt việc kiểm tra tính hợp lệ dữ liệu của các phần tử khác.

2.2 Hỗ trợ có các request chưa được kiểm tra tính hợp lệ
Kiểm tra hợp lệ dữ liệu cho request “trễ” thực ra chưa giải quyết được nhu cầu cần bỏ qua việc kiểm tra hợp lệ dữ liệu cho một phần tử nào đó của request. Lời gọi Request.Form[“forum_post”] vẫn kích hoạt việc kiểm tra hợp lệ cho giá trị của phần tử đó. Tuy nhiên, thực ra bạn vẫn cần đọc được phần tử này mà không kích hoạt việc kiểm tra tính hợp lệ, bởi vì bạn muốn chấp nhận mã đánh dấu được lưu trong trường đó.

Để chấp nhận việc bỏ qua kiểm tra tính hợp lệ, ASP.NET 4.5 bây giờ đã hỗ trợ cho việc bỏ qua kiểm tra hợp lệ bằng cách cung cấp một thuộc tập hợp có tên là Unvalidated trong lớp HttpRequest. Chúng ta có thể sử dụng tập hợp này để truy xuất đến tất cả các giá trị thông dụ như Form, QueryString, Cookies, và Url.

Sử dụng cùng với ví dụ trên, để có thể đọc dữ liệu chưa được kiểm tra hợp lệ, bạn cần phải cấu hình ứng dụng để sử dụng cơ chế kiểm tra tính hợp lệ của request mới:

<httpRuntime requestValidationMode="4.5" ... />
Bạn có thể sử dụng thuộc tính HttpRequest.Unvalidated để đọc các giá trị chưa kiểm tra hợp lệ của form:

var s = context.Request.Unvalidated.Form["forum_post"];
Lưu ý về bảo mật: Mặc dù ASP.NET 4.5 cho phép bạn truy xuất vào dữ liệu chưa được kiểm tra tính hợp lệ của request, nhưng bạn vẫn cần phải tự mình kiểm tra đối với dữ liệu thô lấy từ request để đảm bảo bạn không gởi mã độc trở lại cho khách hàng.

4. Thư viện Anti-XSS

Bởi vì thư viện Microsoft AntiXSS được sử dụng rất phổ biến, ASP.NET 4.5 đã tích hợp tính năng chính của thư viện này (phiên bản 4.0) vào chính nó.

Các kỹ thuật mã hóa được cài đặt bởi kiểu AntiXssEncoder trong namespace mới là System.Web.Security.AntiXss. Bạn có thể dụng kiểu AntiXssEncoder trực tiếp bằng cách gọi bất ký phương thức mã hóa tĩnh nào được cài đặt trong kiểu này. Tuy nhiên, phương thực tiếp cận dễ nhất đó là cấu hình ứng dụng ASP.NET để ứng dụng mặc định sử dụng AntiXssEncoder. Để làm được điều đó, bạn cần thêm thuộc tính sau vào tập tin Web.config:

<httpRuntime ...  encoderType="System.Web.Security.AntiXss.AntiXssEncoder, System.Web,    Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
Dưới đây là các thành phần của thư viện AntiXSS được tích hợp vào ASP.NET 4.5:

  • HtmlEncode, HtmlFormUrlEncode, and HtmlAttributeEncode
  • XmlAttributeEncode and XmlEncode
  • UrlEncode và UrlPathEncode
  • CssEncode
5. Hỗ trợ cho giao thức WebSockets
Giao thức WebSockets là một giao thức mạng chuẩn nhằm định nghĩa cách thiết lập các kết nối hai chiều thời gian thực giữa client và server thông qua giao thức HTTP. Microsoft đã làm việc với các chuẩn IETF và W3C để giúp định nghĩa giao thức này. Giao thức WebSocket được hỗ trợ bởi bất kỳ client nào (không chỉ là browsers).

Giao thức WebSockets giúp cho việc gởi nhận dữ liệu trong thời gian dài giữa client và server dễ dàng hơn. Ví dụ, việc xây dựng một ứng dụng chat sẽ dễ dàng hơn nhiều bởi vì bạn có thể thiếp lập một kết nối “thời gian dài” giữa client và server mà không phải mất công giả lập các tính năng của một socker như trước đây nữa.

ASP.NET 4.5 và IIS 8 bây giờ đã hỗ trợ WebSockets, cho phép các lập trình viên có thể sử dụng APIs để đọc và ghi bất đồng bộ chuỗi và dữ liệu nhị phân trên một đối tượng WebSockets. ASP.NET 4.5 đã có một namespace mới là System.Web.WebSockets chứa các kiểu dành cho việc lập trình với giao thức WebSockets.

Trình duyệt sẽ thiết lập một kết nối WebSockets để tạo một đối tượng DOM là WebSocket mà đối tượng này trỏ đến một URL của ứng dụng ASP.NET, như dưới đây:

socket = new WebSocket("ws://contoso.com/MyWebSocketApplication.ashx");
Bạn có thể tạo các endpoint trong ASP.NET bầng bất cứ module hoặc handler nào. Với ví dụ trên thì chúng ta sử dụng tập tin .ashx, bởi vì tập tin .ashx là cách để có thể thiết lập một hanlder nhanh chóng.

Để áp dụng giao thức WebSockets, ứng dụng ASP.NET chấp nhận một request dạng WebSockets bằng cách xác định rằng request đó nên được nâng cấp từ một request dạng HTTP GET thành request dạng WebSockets. Xem ví dụ dưới:

HttpContext.Current.AcceptWebSocketRequest(// WebSocket delegate ở đây)
Phương thức AcceptWebSocketRequest chấp nhật tham số là một delegate bởi vì ASP.NET sẽ bung HTTP request và chuyển quyền điều khiển đến delegate đó. Cách tiếp cận này khá giống với cách bạn dùng System.Threading.Thread, ở đó bạn sẽ định nghĩa một thread-start delegate mà mọi công việc sẽ được thực hiện bên trong delegate đó.

Sau khi ASP.NET và client đã hoàn thành xong việc thiết lập kết nối thông qua giao thức WebSockets, ASP.NET gọi delegate của bạn và ứng dụng WebSockets sẽ bắt đầu chạy. Mã lệnh dưới đây mih hoạt mã của một ứng dụng sử dụng tính năng hỗ trợ WebSockets của ASP.NET

public async Task MyWebSocket(AspNetWebSocketContext context) {    WebSocket socket = context.WebSocket;    while (true)    {        ArraySegment<byte> buffer = new ArraySegment<byte>(new byte[1024]);         // Asynchronously wait for a message to arrive from a client        WebSocketReceiveResult result =            await socket.ReceiveAsync(buffer, CancellationToken.None);         // If the socket is still open, echo the message back to the client        if (socket.State == WebSocketState.Open)        {            string userMessage = Encoding.UTF8.GetString(buffer.Array, 0,                result.Count);            userMessage = "You sent: " + userMessage + " at " +                DateTime.Now.ToLongTimeString();            buffer = new ArraySegment<byte>(Encoding.UTF8.GetBytes(userMessage));             // Asynchronously send a message to the client            await socket.SendAsync(buffer, WebSocketMessageType.Text,                true, CancellationToken.None);        }        else { break; }    }}
Từ khóa await và các thao tác dạng task-based hoàn toàn phù hợp để xây dựng các ứng dụng WebSockets. Mã lệnh dưới đây cho thấy một request dạng WebSockets chạy hoàn toàn bất đồng bộ bên trong Asp.NET. Ứng dụng này chờ đợi thông điệp một cách bất đồng bộ từ client bằng cách gọi phương thức socket.ReceiveAsync. Tương tự, bạn có thể gởi thông điệp bất đồng bộ đến client bằng cách gọi await socket.SendAsync.

Ở trình duyệt, ứng dụng khách nhận được các thông điệp WebSockets ở hàm onmesssage. Để gởi một thông điệp từ trình duyệt, bạn có thể gọi phương thưng thức send của đối tượng DOM WebSocktet như dưới đây:

// Receive a string message from the server. socket.onmessage = function(msg) {    document.getElementById("serverData").innerHTML = msg.data;  }; // Send a string message from the browser. socket.send(document.getElementById("msgText"));
6. Bundling và Minification

Bundling (gói, bó lại) cho phép bạn gộp nhiều tập tin JavaScript và CSS thành một gói và có thể xem như là một tập tin duy nhất. Minification là việc làm giảm kích thước các tập tin JavaScript và CSS bằng cách xóa các ký tự trắng thừa và các ký tự không cần thiết. Các tính năng này hoạt động với các ứng dụng Web Forms, ASP.NET MVC, và Web Pages.

Tính năng bundling can thiệp vào kỹ thuật định tuyến của ASP.NET và nhờ vậy có khả năng tham chiếu đến cả một thư mục hơn là chỉ tham chiếu đến từng tập tin riêng rẽ. Giả thử bạn có cấu trúc tập tin như sau:



Bạn muốn gói tất cả các tập tin .js trong thư mục Scripts. Để làm điều đó, bạn có thể tham chiếu đến thư mục và nối /js đến đường dẫn như dưới đây:



Bạn cũng có thể gói tất cả các tập tin .css trong thư mục Styles, nhưng thay vì thêm /js, bạn sẽ thêm /css vào đường dẫn:



Khi các tập tin đã được gói lại, chúng được sắp xếp theo thứ tự alphabe (theo cách mà chúng được hiển thị ở Solution Explorer). Sau đó chúng được tổ chức làm sao để các thư viện đã biết và các mở rộng của chúng (như jQuery, MooTools và Dojo) được nạp trước. Ví dụ, thứ tự các tập tin trong thư mục Script được sắp xếp thành gói theo thứ tự:

  1. jquery-1.6.2.js
  2. jquery-ui.js
  3. jquery.tools.js
  4. a.js
Các tập tin CSS cũng được sắp xếp theo thứ tự anphabe và sau đó được tổ chức lại để reset.css và normalize.css được xếp trước. Kết quả sắp xếp cuối cùng của thư mục Styles như dưới đây:

  1. reset.css
  2. content.css
  3. forms.css
  4. globals.css
  5. menu.css
  6. styles.css
Thuật toán sắp xếp cho các tập tin này là có thể tùy biến.

Bạn có thể đăng ký gói của bạn trong thư mục Global.asax để quy định những tập tinnaof sẽ nằm trong gói và đường dẫn URL chính xác như thế nào. Mã dưới dây sẽ cho thấy cách thực hiện:



Và gói tùy biến customscript trong ví dụ có thể được tham chiếu như dưới đây:


Bạn thậm chí có thể thay đổi các thức làm gọn có sẵn bằng các phương thức tùy chọn của bạn. Trong ví dụ dưới đây, các cách làm gọn đựng sẵn được thay thế bới hai kiểu tùy chọn MyJsTransform và MyCssTransform.



Tính năng gói và làm gọn được xây dựng với mục tiêu là dễ dàng mở rộng, và vì vậy mọi phần của tiến trình đều có thể mở rộng và thay thế.

7. Cải thiện tốc độ cho Web Hosting

.NET Framework 4.5 và Windows 8 giới thiệu các tính năng cho phép bạn tăng tốc rõ rệt đối với website. Trong đó thời gian khởi động và dung lượng bộ nhớ sử dụng của các web hosting sử dụng ASP.NET được giảm đến 35%.

7.1 Các yếu tố chủ yếu ảnh hưởng đến tốc độ

Lý tưởng nhất để ứng dụng có tốc độ cao là chúng đã có mặt sẵng sàng trên bộ nhớ để đảm bảo trả lời nhanh chóng cho request tiếp theo khi chúng tới. Các yếu tố làm ảnh hưởng khả năng đáp trả của site gồm:

  • Thời gian cần để site khởi động lại sau khi app pool bị xóa. Đây là thời gian cần để nạp lại một tiến trình của web server dành cho các hợp tập (assemblies) của site mà chúng đã không còn trong bộ nhớ. (Các hợp tập (assemblies) của nền tảng vẫn còn trong bộ nhớ vì chúng vẫn được sử dụng bởi các site khác). Tình huống này thường được gọi là “cold site, warm framework startup” hoặc chỉ là “cold site startup”.
  • Số lượng bộ nhớ mà site chiếm dụng. Thuật ngữ tương ứng là “per-site memory consumption” hoặc “unshared working set”
Các cải tiến mới sẽ tập trung vào các yếu tố trên.

7.2. Yêu cầu dành cho các tính năng cải thiện tốc độ
Các yêu cầu dành cho các tính năng có thể phân làm ba nhóm:

  • Các cải tiến chạy trên .NET Framework 4
  • Các cải tiến yêu cầu .NET Framework 4.5 và có thể chạy trên mọi phiên bản của Windows
  • Các yếu tổ chỉ có mặt trên .NET Framework 4.5 và Windows 8
Tốc độ của ứng dụng sẽ được cải thiện theo mức tăng dần đối với mỗi mức (từ trên xuống) mà bạn có thể áp dụng được.

7.3. Chia sẽ các hợp tập dùng chung

Yêu cầu: .NET Framework 4 và Visual Studio 11 Developer Preview SDK

Các site khác nhau trên cùng một server thường dùng chung một số hợp tập. Mỗi site đều có bản sao của các hợp tập trong thư mục Bin. Mặc dù chúng giống nhau, nhưng mỗi hợp tập như vậy vẫn phải được đọc trong quá trình site khởi động và được lưu riêng biệt trong bộ nhớ.

Tính năng interning mới của sẽ giải quyết sự thiếu hiệu quả này và sẽ giảm yêu cầu về RAM và thời gian nạp site. Tính năng interning giúp Windows chỉ giữ một bản sao của mỗi assembly trong hệ thống tập tin, và các hợp tập riêng biệ trong các thư mục Bin sẽ được thay thế bởi các liên kết đến bản sao duy nhất đó. Nếu như một site nào đó cần một phiên bản riêng biệt của hợp tập, link tượng trưng đó sẽ được thay thế bằng một phiên bản mới của hợp tập và chỉ site đó bị tác động mà thôi.

Để các hợp tập dùng chung sử dụng các liên kết tượng trưng cần phải sử dụng một công cụ mới có tên là aspnet_intent.exe, công cụ này giúp cho bạn tạo và quản lý kho các hợp tập dùng chúng. Nó được cung cấp như là một phần của Visual Studio 11 Developer Preview SDK.

Để đảm bảo tất cả các hợp tập hợp lệ được quản lý, bạn chạy aspnet_intent.exe theo chu kỳ (ví dụ như 1 tuần 1 lần). Cách dùng cụ thể như sau:

aspnet_intern -mode exec -sourcedir"C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NETFiles" -interndir C:\ASPNETCommonAssemblies
Để thấy mọi tùy chọn, hãy chạy công cụ mà không có tham số.

7.4 Sử dụng JIT đa lõi (multi-Core JIT) để biên dịch

Yêu cầu: .NET Framework 4.5

Đối với site được khởi động lạnh, ngoài việc đọc từ đĩa các hợp tập, thì cả site cũng phải được biên dịch (JIT-compiled). Đối với các site phức tạp thì sẽ khá tốn kém thời gian. .NET Framework 4.5 với một kỹ thuật mới sẽ giúp giảm thời gian biên dịch bằng cách tận dụng tất cả cá lõi xử lý rỗi để biên dịch. Nó sẽ làm càng sớm càng tốt bằng cách sử dụng thông tin thu thập được trong những lần nạp site trước. Chức năng này được thiết lập bởi phương thức System.Runtime.ProfileOptimization.StartProfile. Việc biên dịch sử dụng nhiều lõi xử lý được kích hoạt mặc định nên bạn không cần thao tác gì thêm. Tuy nhiên nếu bạn muốn vô hiệu hóa tính năng này thì cần thêm tùy chỉnh này vào tập tin Web.config:

<configuration>  <!-- ... -->  <system.web>    <compilation profileGuidedOptimizations="None"  />  <!-- ... -->  
7.5 Tối ưu garbage collection để tối ưu bộ nhớ

Yêu cầu: .NET Framework 4.5

Một khi site đang chạy, việc nó sẽ sử dụng bộ nhớ heap của bộ thu gom rác (GC) như thế nào là một nhân tố quan quan trọng đối với tổng bộ nhớ mà nó chiếm dụng. Cũng giống như các bộ thu rom rác khác, .NET Framework GC phải cân bằng giữa CPU sử dụng và dung lượng bộ nhớ chiếm dụng (không gian nhớ mở rộng được dùng cho đối tượng mới được giải phóng, hoặc các đối tượng có thể bị giải phóng). Với các phiên bản trước của ASP.NET, Microsoft đã có hướng dẫn cách cấu hình GC để đạt được mức cân bằng tốt.

Đối với .NET Framework 4.5, thay vì sử dụng nhiều cấu hình riêng biệt, có một tùy chỉnh cấu hình được sử dụng để hữu hiệu tất cả các cấu hình GC khuyến dùng trước đó cũng như các cấu hình dùng để tăng tốc tùy theo site.

Để hữu hiệu hóa việc tối ưu bộ nhớ GC, thêm tùy chọn sau vào tập tin Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config:

<configuration>  <!-- ... -->  <runtime>    <performanceScenario value="HighDensityWebHosting"  />  <!-- ... -->  
(Nếu bạn quen thuộc với các hướng dẫn trước để tùy chỉnh aspnet.config, lưu ý rằng tùy chỉnh này sẽ thay thế các tùy chỉnh cũ – ví dụ như không cần phải điều chỉnh gcServer, gcConcurrent,v.v. Bạn không cần phải bỏ đi những tùy chỉnh cũ).

7.6 Nạp trước ứng dụng web

Yêu cầu: .NET Framework 4.5 chạy trên Windows 8

Với một số bản phát hành, Windows được đính kèm một công nghệ được gọi là prefetcher giúp giảm thời lượng đọc ổ cứng khi khởi chạy một ứng dụng. Bởi vì cold startup là vấn đề thường xảy ra ở các ứng dụng khách, nên công nghệ này không được tích hợp vào Windows Server, mà Windows Server chỉ tích hợp một số thành phần cần thiết mà thôi. Prefeching đã có mặt trên phiên bản mới nhất của Windows Server, và nó sẽ giúp cho tối ưu hóa thời gian khởi chạy các website.

Đối với Windows Server, prefercher bị mặc định vô hiệu. Để hữu hiệu hóa và cấu hình nó, chạy các câu lệnh sau từ command line:

sc config sysmain start=autoreg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" /v EnablePrefetcher /t REG_DWORD /d 2 /freg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Prefetcher" /v MaxPrefetchFiles /t REG_DWORD /d 8192 /fnet start sysmain
Sau đó tích hợp prefetcher với các ứng dụng ASP.NET bằng cách thêm nội dung dưới đây vào tâp tin Web.config:

<configuration>  <!-- ... -->  <system.web>    <compilation enablePrefetchOptimization="true" />  <!-- ... -->  
TÓM LẠI:
ASP.NET 4.5 hỗ trợ mạnh cho lập trình bất đồng bộ, hỗ trợ kiểm tra tính hợp dữ liệu cho trường riêng biệt của request, cho phép chúng ta truy xuất được dữ liệu chưa được kiểm ính hợp lệ của của request, hỗ trợ thư viện Anti-XSS, hỗ trợ lập trình với giao thức WebSockets, hỗ trợ đóng gói và nén các tập tin javascript và css, và cuối cùng là một loạt các cải tiến nhằm tăng tốc ứng dụng web. Chỉ với bao nhiêu cái tiến đó thôi cũng đủ cho chúng ta thấy cần thiết phải sẵn sàng để xây dựng ứng dụng web trên nền tảng này.


Tuyên bố Không chịu trách nhiệm Nội dung Giải pháp Cộng đồng

CÔNG TY MICROSOFT VÀ/HOẶC CÁC NHÀ CUNG CẤP CỦA HỌ KHÔNG BẢO ĐẢM VỀ TÍNH PHÙ HỢP, ĐỘ TIN CẬY HOẶC TÍNH CHÍNH XÁC CỦA THÔNG TIN VÀ HÌNH ẢNH LIÊN QUAN Ở ĐÂY. MỌI THÔNG TIN VÀ HÌNH ẢNH NHƯ VẬY ĐƯỢC CUNG CẤP “NHƯ NGUYÊN MẪU” MÀ KHÔNG CÓ BẤT KỲ BẢO ĐẢM NÀO. MICROSOFT VÀ/HOẶC CÁC NHÀ CUNG CẤP CỦA HỌ KHÔNG CHỊU TRÁCH NHIỆM ĐỐI VỚI MỌI BẢO ĐẢM VÀ ĐIỀU KIỆN VỀ THÔNG TIN VÀ HÌNH ẢNH LIÊN QUAN NÀY, BAO GỒM CẢ MỌI BẢO ĐẢM VÀ ĐIỀU KIỆN LIÊN QUAN VỀ TÍNH THƯƠNG MẠI, PHÙ HỢP CHO MỘT MỤC ĐÍCH ĐẶC BIỆT, NỖ LỰC CỦA CÔNG VIỆC, TƯ CÁCH VÀ CAM KẾT KHÔNG VI PHẠM. BẠN ĐỒNG Ý MỘT CÁCH CỤ THỂ LÀ KHÔNG CÓ TRƯỜNG HỢP NÀO MÀ MICROSOFT VÀ/HOẶC CÁC NHÀ CUNG CẤP CỦA HỌ BỊ RÀNG BUỘC VÀO BẤT KỲ THIỆT HẠI TRỰC TIẾP, GIÁN TIẾP, TRỪNG PHẠT, TÌNH CỜ, ĐẶC BIỆT, HỆ QUẢ HOẶC BẤT KỲ THIỆT HẠI DẠNG NÀO, BAO GỒM NHƯNG KHÔNG GIỚI HẠN THIỆT HẠI DO MẤT MÁT, DỮ LIỆU HOẶC LỢI ÍCH, XẢY RA HOẶC TRONG MỌI CÁCH LIÊN QUAN ĐẾN VIỆC SỬ DỤNG HOẶC KHÔNG THỂ SỬ DỤNG THÔNG TIN VÀ HÌNH ẢNH LIÊN QUAN CÓ Ở ĐÂY, DÙ LÀ DỰA VÀO HỢP ĐỒNG, LỖI GÂY THIỆT HẠI, SƠ SUẤT, NGHĨA VỤ PHÁP LÝ HOẶC BẤT KỲ CƠ SỞ NÀO KHÁC, NGAY CẢ NẾU MICROSOFT HOẶC BẤT KỲ NHÀ CUNG CẤP NÀO CỦA HỌ ĐÃ ĐƯỢC TƯ VẤN VỀ KHẢ NĂNG BỊ THIỆT HẠI.
Thuộc tính

ID Bài viết: 2645847 - Xem lại Lần cuối: 12/14/2011 03:28:00 - Bản sửa đổi: 2.0

  • Microsoft ASP.NET 4.0
  • kbprb kbtshoot kbstepbystep kbgraphxlink kbmvp KB2645847
Phản hồi