Tôi mới phát hiện ra lý do tại sao tất cả các trang web của ASP.Net đều chậm và tôi đang cố gắng tìm ra những gì cần làm về nó

Tôi mới phát hiện ra rằng mọi yêu cầu trong ứng dụng web ASP.Net đều có Khóa phiên khi bắt đầu yêu cầu và sau đó phát hành vào cuối yêu cầu!

Trong trường hợp ý nghĩa của việc này bị mất đối với bạn, vì nó là cho tôi lúc đầu, điều này về cơ bản có nghĩa như sau:

• Bất cứ khi nào một trang web ASP.Net mất nhiều thời gian để tải (có thể do cuộc gọi cơ sở dữ liệu chậm hoặc bất cứ điều gì) và người dùng quyết định họ muốn điều hướng đến một trang khác vì họ mệt mỏi vì phải chờ đợi, HỌ KHÔNG THỂ! Khóa phiên ASP.Net buộc yêu cầu trang mới phải đợi cho đến khi yêu cầu ban đầu kết thúc tải chậm một cách đau đớn. Arrrgh.

• Bất cứ khi nào UpdatePanel tải chậm và người dùng quyết định điều hướng đến một trang khác trước khi UpdatePanel cập nhật xong ... HỌ KHÔNG THỂ! Khóa phiên ASP.net buộc yêu cầu trang mới phải đợi cho đến khi yêu cầu ban đầu kết thúc tải chậm một cách đau đớn. Đôi Arrrgh!

Vậy những lựa chọn là gì? Cho đến nay tôi đã nghĩ ra:

• Triển khai một sessionStateDataStore tùy chỉnh, mà ASP.Net hỗ trợ. Tôi đã không tìm thấy quá nhiều thứ để sao chép, và nó có vẻ như có nguy cơ cao và dễ gây rối.
• Theo dõi tất cả các yêu cầu đang diễn ra và nếu một yêu cầu đến từ cùng một người dùng, hãy hủy yêu cầu ban đầu. Có vẻ như cực đoan, nhưng nó sẽ làm việc (tôi nghĩ).
• Đừng sử dụng Phiên! Khi tôi cần một số trạng thái cho người dùng, tôi chỉ có thể sử dụng Cache và các mục chính trên tên người dùng được xác thực hoặc một số thứ như vậy. Một lần nữa có vẻ như cực đoan.

Tôi thực sự không thể tin rằng nhóm Microsoft của ASP.Net sẽ để lại một nút cổ chai hiệu năng lớn như vậy trong khuôn khổ ở phiên bản 4.0! Tôi có thiếu một cái gì đó rõ ràng? Việc sử dụng bộ sưu tập ThreadSafe cho Phiên sẽ khó đến mức nào?

Nếu trang của bạn không sửa đổi bất kỳ biến phiên nào, bạn có thể chọn không tham gia khóa này.

<% @Page EnableSessionState="ReadOnly" %>

Nếu trang của bạn không đọc bất kỳ biến phiên nào, bạn có thể chọn hoàn toàn khóa này cho trang đó.

<% @Page EnableSessionState="False" %>

Nếu không có trang nào của bạn sử dụng biến phiên, chỉ cần tắt trạng thái phiên trong web.config.

<sessionState mode="Off" />

Tôi tò mò, bạn nghĩ "bộ sưu tập ThreadSafe" sẽ làm gì để trở nên an toàn cho chủ đề, nếu nó không sử dụng khóa?

Chỉnh sửa: Tôi có lẽ nên giải thích bằng những gì tôi có nghĩa là "từ chối hầu hết các khóa này". Bất kỳ số lượng trang chỉ đọc hoặc phiên không có phiên có thể được xử lý cho một phiên nhất định cùng một lúc mà không chặn nhau. Tuy nhiên, trang phiên đọc-ghi không thể bắt đầu xử lý cho đến khi tất cả các yêu cầu chỉ đọc đã hoàn thành và trong khi nó đang chạy, nó phải có quyền truy cập độc quyền vào phiên của người dùng đó để duy trì tính nhất quán. Khóa trên các giá trị riêng lẻ sẽ không hoạt động, vì nếu một trang thay đổi một tập hợp các giá trị liên quan thành một nhóm thì sao? Làm thế nào bạn có thể đảm bảo rằng các trang khác đang chạy cùng một lúc sẽ có được cái nhìn nhất quán về các biến phiên của người dùng?

Tôi sẽ đề nghị bạn cố gắng giảm thiểu việc sửa đổi các biến phiên sau khi chúng đã được đặt, nếu có thể. Điều này sẽ cho phép bạn tạo phần lớn các trang chỉ đọc các phiên, tăng khả năng nhiều yêu cầu đồng thời từ cùng một người dùng sẽ không chặn nhau.

OK, Đạo cụ lớn cho Joel Muller cho tất cả đầu vào của anh ấy. Giải pháp cuối cùng của tôi là sử dụng CustomStateModule tùy chỉnh chi tiết ở cuối bài viết MSDN này:

http://msdn.microsoft.com/en-us/l Library / system.web.sessionstate.sessionstateutility.aspx

Đây là:

• Thực hiện rất nhanh (thực sự có vẻ dễ hơn là đi theo lộ trình của nhà cung cấp)
• Đã sử dụng rất nhiều cách xử lý phiên ASP.Net tiêu chuẩn (thông qua lớp SessionStateUtility)

Điều này đã tạo ra một sự khác biệt lớn cho cảm giác "nhanh nhẹn" đối với ứng dụng của chúng tôi. Tôi vẫn không thể tin rằng việc triển khai tùy chỉnh Phiên ASP.Net khóa phiên cho toàn bộ yêu cầu. Điều này thêm một số lượng lớn chậm chạp như vậy cho các trang web. Đánh giá từ số lượng nghiên cứu trực tuyến tôi phải thực hiện (và các cuộc trò chuyện với một số nhà phát triển ASP.Net thực sự có kinh nghiệm), rất nhiều người đã gặp phải vấn đề này, nhưng rất ít người đã đi đến tận cùng của nguyên nhân. Có lẽ tôi sẽ viết một lá thư cho Scott Gu ...

Tôi hy vọng điều này sẽ giúp một vài người ngoài kia!

Tôi đã bắt đầu sử dụng AngiesList.Redis.RedisSessionStateModule , ngoài việc sử dụng máy chủ Redis (rất nhanh) để lưu trữ (tôi đang sử dụng cổng windows - mặc dù cũng có cổng MSOpenTech ), nhưng nó hoàn toàn không khóa trong phiên .

Theo tôi, nếu ứng dụng của bạn được cấu trúc một cách hợp lý, đây không phải là vấn đề. Nếu bạn thực sự cần khóa, dữ liệu nhất quán như một phần của phiên, bạn nên tự mình thực hiện kiểm tra khóa / đồng thời.

MS quyết định rằng mọi phiên ASP.NET nên được khóa theo mặc định chỉ để xử lý thiết kế ứng dụng kém là một quyết định tồi, theo ý kiến ​​của tôi. Đặc biệt là vì có vẻ như hầu hết các nhà phát triển thậm chí không nhận ra các phiên đã bị khóa, chứ đừng nói rằng các ứng dụng rõ ràng cần phải được cấu trúc để bạn có thể thực hiện trạng thái phiên chỉ đọc càng nhiều càng tốt (từ chối, nếu có thể) .

Tôi đã chuẩn bị một thư viện dựa trên các liên kết được đăng trong chủ đề này. Nó sử dụng các ví dụ từ MSDN và CodeProject. Cảm ơn James.

Tôi cũng đã thực hiện các sửa đổi được tư vấn bởi Joel Mueller.

Mã ở đây:

https://github.com/dermeister0/LockFreeSessionState

Mô-đun HashTable:

Install-Package Heavysoft.LockFreeSessionState.HashTable

Mô-đun StateServer của ScaleOut:

Install-Package Heavysoft.LockFreeSessionState.Soss

Mô-đun tùy chỉnh:

Install-Package Heavysoft.LockFreeSessionState.Common

Nếu bạn muốn triển khai hỗ trợ Memcached hoặc Redis, hãy cài đặt gói này. Sau đó, kế thừa lớp LockFreeSessionStateModule và thực hiện các phương thức trừu tượng.

Mã này chưa được thử nghiệm trên sản xuất. Cũng cần cải thiện xử lý lỗi. Các ngoại lệ không được bắt gặp trong việc thực hiện hiện tại.

Một số nhà cung cấp phiên không khóa sử dụng Redis:

• https://github.com/angieslist/AL-Redis (Được đề xuất bởi gregmac trong chủ đề này.)
• https://github.com/welegan/RedisSessionProvider (NuGet: RedisSessionProvider)
• https://github.com/efaruk/playground/tree/master/UnlockedStateProvider (NuGet: UnlockedStateProvider.Redis)

Trừ khi ứng dụng của bạn có nhu cầu đặc biệt, tôi nghĩ bạn có 2 cách tiếp cận:

1. Không sử dụng phiên nào cả
2. Sử dụng phiên như hiện tại và thực hiện tinh chỉnh như joel đã đề cập.

Phiên không chỉ an toàn theo luồng mà còn an toàn trạng thái, theo cách mà bạn biết rằng cho đến khi yêu cầu hiện tại được hoàn thành, mọi biến phiên sẽ không thay đổi từ yêu cầu hoạt động khác. Để điều này xảy ra, bạn phải đảm bảo rằng phiên SILL ĐƯỢC KHÓA cho đến khi yêu cầu hiện tại hoàn thành.

Bạn có thể tạo một phiên giống như hành vi bằng nhiều cách, nhưng nếu nó không khóa phiên hiện tại, thì đó sẽ không phải là 'phiên'.

Đối với các vấn đề cụ thể mà bạn đã đề cập, tôi nghĩ bạn nên kiểm tra HttpContext.Cản.Response.IsClientConnected . Điều này có thể hữu ích để ngăn chặn các thực thi và chờ đợi không cần thiết trên máy khách, mặc dù nó không thể giải quyết vấn đề này hoàn toàn, vì điều này chỉ có thể được sử dụng bằng cách gộp chung và không đồng bộ.

Nếu bạn đang sử dụng bản cập nhật Microsoft.Web.RedisSessionStateProvider(bắt đầu từ 3.0.2), bạn có thể thêm phần này vào web.configđể cho phép các phiên đồng thời.

<appSettings>
    <add key="aspnet:AllowConcurrentRequestsPerSession" value="true"/>
</appSettings>

Nguồn

Đối với ASPNET MVC, chúng tôi đã làm như sau:

1. Theo mặc định, đặt SessionStateBehavior.ReadOnly trên tất cả hành động của bộ điều khiển bằng cách ghi đèDefaultControllerFactory
2. Trên các hành động của bộ điều khiển cần ghi vào trạng thái phiên, đánh dấu bằng thuộc tính để đặt thành SessionStateBehavior.Required

Tạo Trình điều khiển tùy chỉnh và ghi đè GetControllerSessionBehavior.

    protected override SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, Type controllerType)
    {
        var DefaultSessionStateBehaviour = SessionStateBehaviour.ReadOnly;

        if (controllerType == null)
            return DefaultSessionStateBehaviour;

        var isRequireSessionWrite =
            controllerType.GetCustomAttributes<AcquireSessionLock>(inherit: true).FirstOrDefault() != null;

        if (isRequireSessionWrite)
            return SessionStateBehavior.Required;

        var actionName = requestContext.RouteData.Values["action"].ToString();
        MethodInfo actionMethodInfo;

        try
        {
            actionMethodInfo = controllerType.GetMethod(actionName, BindingFlags.IgnoreCase | BindingFlags.Public | BindingFlags.Instance);
        }
        catch (AmbiguousMatchException)
        {
            var httpRequestTypeAttr = GetHttpRequestTypeAttr(requestContext.HttpContext.Request.HttpMethod);

            actionMethodInfo =
                controllerType.GetMethods().FirstOrDefault(
                    mi => mi.Name.Equals(actionName, StringComparison.CurrentCultureIgnoreCase) && mi.GetCustomAttributes(httpRequestTypeAttr, false).Length > 0);
        }

        if (actionMethodInfo == null)
            return DefaultSessionStateBehaviour;

        isRequireSessionWrite = actionMethodInfo.GetCustomAttributes<AcquireSessionLock>(inherit: false).FirstOrDefault() != null;

         return isRequireSessionWrite ? SessionStateBehavior.Required : DefaultSessionStateBehaviour;
    }

    private static Type GetHttpRequestTypeAttr(string httpMethod) 
    {
        switch (httpMethod)
        {
            case "GET":
                return typeof(HttpGetAttribute);
            case "POST":
                return typeof(HttpPostAttribute);
            case "PUT":
                return typeof(HttpPutAttribute);
            case "DELETE":
                return typeof(HttpDeleteAttribute);
            case "HEAD":
                return typeof(HttpHeadAttribute);
            case "PATCH":
                return typeof(HttpPatchAttribute);
            case "OPTIONS":
                return typeof(HttpOptionsAttribute);
        }

        throw new NotSupportedException("unable to determine http method");
    }

Mua lạiSessionLockAttribution

[AttributeUsage(AttributeTargets.Method)]
public sealed class AcquireSessionLock : Attribute
{ }

Kết nối nhà máy điều khiển đã tạo global.asax.cs

ControllerBuilder.Current.SetControllerFactory(typeof(DefaultReadOnlySessionStateControllerFactory));

Bây giờ, chúng ta có thể có cả hai read-onlyvà read-writetrạng thái phiên trong một Controller.

public class TestController : Controller 
{
    [AcquireSessionLock]
    public ActionResult WriteSession()
    {
        var timeNow = DateTimeOffset.UtcNow.ToString();
        Session["key"] = timeNow;
        return Json(timeNow, JsonRequestBehavior.AllowGet);
    }

    public ActionResult ReadSession()
    {
        var timeNow = Session["key"];
        return Json(timeNow ?? "empty", JsonRequestBehavior.AllowGet);
    }
}

Lưu ý: Trạng thái phiên ASPNET vẫn có thể được ghi ngay cả ở chế độ chỉ đọc và sẽ không ném bất kỳ hình thức ngoại lệ nào (Nó không khóa để đảm bảo tính nhất quán) vì vậy chúng tôi phải cẩn thận đánh dấu AcquireSessionLocktrong các hành động của bộ điều khiển yêu cầu trạng thái phiên viết.

Đánh dấu trạng thái phiên của bộ điều khiển là chỉ đọc hoặc bị vô hiệu hóa sẽ giải quyết vấn đề.

Bạn có thể trang trí bộ điều khiển với thuộc tính sau để đánh dấu nó chỉ đọc:

[SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)]

các System.Web.SessionState.SessionStateBehavior enum có các giá trị sau:

• Mặc định
• Tàn tật
• Chỉ đọc
• Cần thiết

Chỉ để giúp bất cứ ai có vấn đề này (khóa yêu cầu khi thực hiện một yêu cầu khác từ cùng một phiên) ...

Hôm nay tôi bắt đầu giải quyết vấn đề này và, sau vài giờ nghiên cứu, tôi đã giải quyết nó bằng cách xóa Session_Startphương thức (ngay cả khi trống) khỏi tệp Global.asax .

Điều này hoạt động trong tất cả các dự án tôi đã thử nghiệm.

Sau khi vật lộn với tất cả các tùy chọn có sẵn, cuối cùng tôi đã viết một nhà cung cấp SessionStore dựa trên mã thông báo JWT (phiên di chuyển bên trong cookie và không cần lưu trữ phụ trợ).

http://www.drupalonwindows.com/en/content/token-sessionstate

Ưu điểm:

• Thay thế thả vào, không cần thay đổi mã của bạn
• Quy mô tốt hơn bất kỳ cửa hàng tập trung nào khác, vì không cần phụ trợ lưu trữ phiên.
• Nhanh hơn bất kỳ lưu trữ phiên nào khác, vì không cần lấy dữ liệu từ bất kỳ lưu trữ phiên nào
• Không sử dụng tài nguyên máy chủ để lưu trữ phiên.
• Triển khai không chặn mặc định: yêu cầu đồng thời sẽ không chặn nhau và giữ khóa trong phiên
• Mở rộng quy mô ứng dụng của bạn: vì dữ liệu phiên di chuyển với chính yêu cầu, bạn có thể có nhiều đầu web mà không phải lo lắng về việc chia sẻ phiên.