Właśnie odkryłem, dlaczego wszystkie strony ASP.Net są wolne i staram się dowiedzieć, co z tym zrobić

Właśnie odkryłem, że każde żądanie w aplikacji sieci web ASP.Net otrzymuje blokadę sesji na początku żądania, a następnie zwalnia je na końcu żądania!

W przypadku, gdy konsekwencje tego zostaną dla ciebie utracone, tak jak na początku dla mnie, oznacza to w zasadzie:

• Za każdym razem, gdy strona ASP.Net ładuje się długo (być może z powodu powolnego wywołania bazy danych lub cokolwiek innego), a użytkownik decyduje, że chce przejść do innej strony, ponieważ ma dość czekania, NIE MOGĄ! Blokada sesji ASP.Net zmusza nowe żądanie strony do czekania, aż oryginalne żądanie zakończy się boleśnie powolnym ładowaniem. Arrrgh.

• Za każdym razem, gdy UpdatePanel ładuje się powoli, a użytkownik decyduje się przejść do innej strony, zanim UpdatePanel zakończy aktualizację ... NIE MOGĄ! Blokada sesji ASP.net zmusza nowe żądanie strony do czekania, aż oryginalne żądanie zakończy się boleśnie powolnym ładowaniem. Double Arrrgh!

Jakie są więc opcje? Do tej pory wymyśliłem:

• Zaimplementuj niestandardowy SessionStateDataStore, który obsługuje ASP.Net. Nie znalazłem zbyt wielu do skopiowania i wydaje się to dość ryzykowne i łatwe do zepsucia.
• Śledź wszystkie żądania w toku, a jeśli żądanie pochodzi od tego samego użytkownika, anuluj pierwotne żądanie. Wydaje się to trochę ekstremalne, ale zadziałałoby (tak myślę).
• Nie używaj sesji! Kiedy potrzebuję jakiegoś stanu dla użytkownika, mógłbym po prostu użyć pamięci podręcznej zamiast tego i wprowadzić kluczowe elementy w uwierzytelnionej nazwie użytkownika lub coś w tym rodzaju. Znowu wydaje się to ekstremalne.

Naprawdę nie mogę uwierzyć, że zespół ASP.Net Microsoft pozostawiłby tak ogromne wąskie gardło w zakresie wydajności w wersji 4.0! Czy brakuje mi czegoś oczywistego? Jak trudno byłoby użyć kolekcji ThreadSafe do sesji?

Jeśli twoja strona nie modyfikuje żadnych zmiennych sesji, możesz zrezygnować z większości tej blokady.

<% @Page EnableSessionState="ReadOnly" %>

Jeśli strona nie odczytuje żadnych zmiennych sesji, możesz całkowicie zrezygnować z tej blokady dla tej strony.

<% @Page EnableSessionState="False" %>

Jeśli żadna ze stron nie używa zmiennych sesji, po prostu wyłącz stan sesji w pliku web.config.

<sessionState mode="Off" />

Ciekawe, co według ciebie zrobiłaby „kolekcja ThreadSafe”, aby stać się bezpieczną dla wątków, jeśli nie używa zamków?

Edycja: Prawdopodobnie powinienem wyjaśnić, co mam na myśli, mówiąc „zrezygnuj z większości tego zamka”. Dowolna liczba stron sesji tylko do odczytu lub stron bez sesji może być przetwarzana dla danej sesji jednocześnie bez wzajemnego blokowania. Jednak strona sesji odczytu-zapisu nie może rozpocząć przetwarzania, dopóki wszystkie żądania tylko do odczytu nie zostaną zakończone, a podczas działania musi mieć wyłączny dostęp do sesji tego użytkownika, aby zachować spójność. Blokowanie poszczególnych wartości nie działałoby, ponieważ co, jeśli jedna strona zmienia zestaw powiązanych wartości jako grupę? W jaki sposób zapewniłbyś, że inne strony działające w tym samym czasie uzyskałyby spójny widok zmiennych sesji użytkownika?

Sugeruję, abyś próbował zminimalizować modyfikowanie zmiennych sesji po ich ustawieniu, jeśli to możliwe. Pozwoliłoby to na uczynienie większości stron stronami sesji tylko do odczytu, zwiększając prawdopodobieństwo, że wiele jednoczesnych żądań od tego samego użytkownika nie blokuje się nawzajem.

OK, wielkie rekwizyty dla Joela Mullera za cały jego wkład. Moim najlepszym rozwiązaniem było użycie niestandardowego modułu SessionStateModule opisanego na końcu tego artykułu MSDN:

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

To było:

• Bardzo szybki do wdrożenia (w rzeczywistości wydawał się łatwiejszy niż wybranie trasy dostawcy)
• Użyłem dużo standardowej obsługi sesji ASP.Net po wyjęciu z pudełka (za pośrednictwem klasy SessionStateUtility)

To ogromnie wpłynęło na poczucie „zgryźliwości” w naszej aplikacji. Nadal nie mogę uwierzyć, że niestandardowa implementacja sesji ASP.Net blokuje sesję dla całego żądania. To dodaje tak ogromnej ospałości stronom internetowym. Sądząc po ilości badań, które musiałem przeprowadzić (i rozmów z kilkoma naprawdę doświadczonymi programistami ASP.Net), wiele osób doświadczyło tego problemu, ale bardzo niewiele osób doszło do sedna sprawy. Może napiszę list do Scotta Gu ...

Mam nadzieję, że pomoże to kilku osobom!

Zacząłem używać AngiesList.Redis.RedisSessionStateModule , który oprócz używania (bardzo szybkiego) serwera Redis do przechowywania (korzystam z portu systemu Windows - chociaż jest też port MSOpenTech ), absolutnie nie blokuje sesji .

Moim zdaniem, jeśli twoja aplikacja ma rozsądną strukturę, nie stanowi to problemu. Jeśli faktycznie potrzebujesz zablokowanych, spójnych danych w ramach sesji, powinieneś osobiście wdrożyć kontrolę blokady / współbieżności.

MS decydujące, że każda sesja ASP.NET powinna być domyślnie zablokowana tylko w celu obsługi złego projektu aplikacji, jest moim zdaniem złą decyzją. Zwłaszcza, że ​​wydaje się, że większość programistów nie zdawała sobie sprawy, że sesje były zablokowane, nie mówiąc już o tym, że aplikacje najwyraźniej muszą mieć taką strukturę, aby można było wykonywać stan sesji tylko do odczytu (w miarę możliwości). .

Przygotowałem bibliotekę na podstawie linków zamieszczonych w tym wątku. Wykorzystuje przykłady z MSDN i CodeProject. Dzięki Jamesowi.

Dokonałem również modyfikacji zalecanych przez Joela Muellera.

Kod jest tutaj:

https://github.com/dermeister0/LockFreeSessionState

Moduł HashTable:

Install-Package Heavysoft.LockFreeSessionState.HashTable

Moduł ScaleOut StateServer:

Install-Package Heavysoft.LockFreeSessionState.Soss

Moduł niestandardowy:

Install-Package Heavysoft.LockFreeSessionState.Common

Jeśli chcesz wdrożyć obsługę Memcached lub Redis, zainstaluj ten pakiet. Następnie odziedzicz klasę LockFreeSessionStateModule i zaimplementuj metody abstrakcyjne.

Kod nie został jeszcze przetestowany pod kątem produkcji. Również należy poprawić obsługę błędów. Wyjątki nie są wychwytywane w bieżącej implementacji.

Niektórzy dostawcy sesji bez blokady korzystający z Redis:

• https://github.com/angieslist/AL-Redis (sugerowane przez gregmac w tym wątku.)
• https://github.com/welegan/RedisSessionProvider (NuGet: RedisSessionProvider)
• https://github.com/efaruk/playground/tree/master/UnlockedStateProvider (NuGet: UnlockedStateProvider.Redis)

Chyba że twoja aplikacja ma specjalne potrzeby, myślę, że masz 2 podejścia:

1. W ogóle nie używaj sesji
2. Używaj sesji w takiej postaci, w jakiej się znajdują i wykonuj dostrajanie, jak wspomniano joel.

Sesja jest nie tylko bezpieczna dla wątków, ale także bezpieczna dla stanu, w taki sposób, że wiesz, że dopóki bieżące żądanie nie zostanie zakończone, każda zmienna sesji nie zmieni się z innego aktywnego żądania. Aby tak się stało, musisz upewnić się, że sesja ZOSTANIE ZABLOKOWANA do czasu zakończenia bieżącego żądania.

Możesz utworzyć zachowanie podobne do sesji na wiele sposobów, ale jeśli nie zablokuje ono bieżącej sesji, nie będzie to „sesja”.

Dla konkretnych problemów, o których wspomniałeś, myślę, że powinieneś sprawdzić HttpContext.Current.Response.IsClientConnected . Może to być użyteczne, aby zapobiec niepotrzebnym wykonaniom i czeka na klienta, chociaż nie może całkowicie rozwiązać tego problemu, ponieważ można go użyć tylko w trybie puli, a nie asynchronizacji.

Jeśli używasz zaktualizowanego Microsoft.Web.RedisSessionStateProvider(od 3.0.2), możesz dodać to do swojego, web.configaby umożliwić równoczesne sesje.

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

Źródło

W przypadku ASPNET MVC wykonaliśmy następujące czynności:

1. Domyślnie SessionStateBehavior.ReadOnlynadpisuj wszystkie działania kontroleraDefaultControllerFactory
2. W przypadku akcji kontrolera, które wymagają zapisu do stanu sesji, zaznacz atrybut, aby to ustawić SessionStateBehavior.Required

Utwórz niestandardowy obiekt ControllerFactory i zastąp 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");
    }

AcquireSessionLockAttribute

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

Podłącz utworzoną fabrykę kontrolerów w global.asax.cs

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

Teraz możemy mieć zarówno stan sesji, jak read-onlyi read-writesesję w jednym 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);
    }
}

Uwaga: Stan sesji ASPNET może być nadal zapisywany nawet w trybie tylko do odczytu i nie wyrzuci żadnej formy wyjątku (po prostu nie blokuje się, aby zagwarantować spójność), dlatego musimy być ostrożni, aby zaznaczyć AcquireSessionLockdziałania kontrolera wymagające stanu zapisu.

Oznaczanie stanu sesji kontrolera jako tylko do odczytu lub wyłączone spowoduje rozwiązanie problemu.

Możesz ozdobić kontroler następującym atrybutem, aby oznaczyć go jako tylko do odczytu:

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

System.Web.SessionState.SessionStateBehavior enum ma następujące wartości:

• Domyślna
• Niepełnosprawny
• Tylko czytać
• wymagany

Tylko po to, aby pomóc każdemu z tym problemem (blokowanie żądań podczas wykonywania innego z tej samej sesji) ...

Dzisiaj zacząłem rozwiązywać ten problem i po kilku godzinach badań rozwiązałem go, usuwając Session_Startmetodę (nawet jeśli pustą) z Global.asax pliku .

Działa to we wszystkich testowanych projektach.

Po zmaganiu się ze wszystkimi dostępnymi opcjami skończyłem pisać dostawcy SessionStore opartego na tokenach JWT (sesja podróżuje wewnątrz pliku cookie i nie jest potrzebne przechowywanie wewnętrznej bazy danych).

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

Zalety:

• Wymiana drop-in, żadne zmiany w kodzie nie są potrzebne
• Skaluj lepiej niż jakikolwiek inny scentralizowany sklep, ponieważ nie jest wymagany backend pamięci sesji.
• Szybsze niż jakakolwiek inna pamięć sesji, ponieważ nie trzeba pobierać danych z pamięci sesji
• Nie zużywa zasobów serwera do przechowywania sesji.
• Domyślna implementacja nieblokująca: współbieżne żądanie nie blokuje się nawzajem i nie blokuje sesji
• Skaluj aplikację w poziomie: ponieważ dane sesji przesyłane są wraz z samym żądaniem, możesz mieć wielu szefów stron internetowych, nie martwiąc się o udostępnianie sesji.