Я тільки що з’ясував, чому всі веб-сайти ASP.Net повільні, і я намагаюся розібратися, що з цим робити

Щойно я виявив, що кожен запит у веб-додатку ASP.Net отримує блокування сеансу на початку запиту, а потім випускає його в кінці запиту!

Якщо наслідки цього втрачаються на вас, як це було для мене спочатку, це в основному означає наступне:

• Кожен раз, коли веб-сторінка ASP.Net потребує тривалого завантаження (можливо, через повільний дзвінок до бази даних чи що завгодно), і користувач вирішує, що хоче перейти на іншу сторінку, оскільки втомився чекати, НЕ МОЖЕ! Блокування сеансу ASP.Net змушує новий запит на сторінку чекати, поки початковий запит не закінчиться його болісно повільним завантаженням. Arrrgh.

• Будь-який час UpdatePanel завантажується повільно, і користувач вирішує перейти на іншу сторінку, перш ніж UpdatePanel закінчить оновлення ... НЕ МОЖЕ! Блокування сеансу ASP.net змушує новий запит на сторінку чекати, поки оригінальний запит не закінчиться його болісно повільним завантаженням. Подвійний Арррх!

То які варіанти? Поки що я придумав:

• Реалізуйте власну SessionStateDataStore, яку підтримує ASP.Net. Я не знайшов занадто багато, щоб скопіювати це, і, здається, це щось з високим ризиком і легко зіпсувати.
• Слідкуйте за всіма запитами, що виконуються, і якщо запит надходить від того самого користувача, скасуйте оригінальний запит. Начебто екстремальний, але це би спрацювало (я думаю).
• Не використовуйте сесію! Коли мені потрібен якийсь стан для користувача, я можу просто використовувати кеш, а також ключові елементи автентифікованого імені користувача або щось подібне. Знову здається свого роду крайнім.

Я дійсно не можу повірити, що команда Microsoft ASP.Net залишила б таке величезне вузьке місце в рамках версії 4.0! Невже я пропускаю щось очевидне? Наскільки важко було б використовувати колекцію ThreadSafe для сесії?

Якщо ваша сторінка не змінює жодних змінних сеансів, ви можете вимкнути більшість цього блокування.

<% @Page EnableSessionState="ReadOnly" %>

Якщо ваша сторінка не читає жодних змінних сеансів, ви можете повністю відмовитись від цього блокування для цієї сторінки.

<% @Page EnableSessionState="False" %>

Якщо жодна з ваших сторінок не використовує змінні сеансу, просто вимкніть стан сеансу в web.config.

<sessionState mode="Off" />

Мені цікаво, як ви думаєте, що б зробити "колекцію ThreadSafe", щоб стати безпечною для потоків, якщо вона не використовує замки?

Редагувати: я, мабуть, повинен пояснити, що я маю на увазі під «відмовою від більшості цього блокування». Будь-яка кількість сторінок сеансу лише для читання або без сеансу може бути оброблена за певний сеанс одночасно, не блокуючи одна одну. Однак сторінка сеансу читання-запису не може почати обробку до тих пір, поки всі запити лише для читання не будуть виконані, і під час її запуску вона повинна мати ексклюзивний доступ до сеансу цього користувача, щоб зберегти послідовність. Блокування окремих значень не буде працювати, бо що робити, якщо одна сторінка змінює набір пов'язаних значень як група? Як би ви гарантували, що інші сторінки, що працюють одночасно, отримають послідовний вигляд змінних сеансів користувача?

Я б запропонував вам спробувати мінімізувати модифікацію змінних сеансу після їх встановлення, якщо це можливо. Це дозволить зробити більшість ваших сторінок для читання лише сеансом, збільшивши ймовірність того, що кілька одночасних запитів від одного користувача не заблокують один одного.

Добре, такі великі реквізити Джоелу Мюллеру за весь його внесок. Моє остаточне рішення - використовувати користувальницький SessionStateModule, детально описаний в кінці цієї статті MSDN:

http://msdn.microsoft.com/en-us/library/system.web.sesionstate.sesionstateutility.aspx

Це було:

• Дуже швидкий втілення (насправді здалося простіше, ніж їхати маршрутом постачальника)
• Використовується багато стандартних операцій з сеансом ASP.Net поза коробкою (через клас SessionStateUtility)

Це зробило ВЕЛИЧЕЗНУ зміну у відчутті "швидкості" до нашого додатку. Я все ще не можу повірити, що власна реалізація ASP.Net Session блокує сеанс для всього запиту. Це додає такої величезної кількості млявості веб-сайтів. Судячи з кількості інтернет-досліджень, які мені довелося провести (і розмов з кількома дійсно досвідченими розробниками ASP.Net), багато людей стикалися з цим питанням, але дуже мало людей коли-небудь дісталися до суті справи. Можливо, я напишу лист Скотту Гу ...

Я сподіваюся, що це допомагає кільком людям там!

Я почав використовувати AngiesList.Redis.RedisSessionStateModule , який окрім використання (дуже швидкого) сервера Redis для зберігання (я використовую порт Windows, хоча є і порт MSOpenTech ), він абсолютно не блокує сеанс .

На мою думку, якщо ваша програма структурована розумним чином, це не проблема. Якщо вам потрібні заблоковані, послідовні дані в рамках сеансу, вам слід спеціально здійснити перевірку блокування / сумісності самостійно.

MS, вирішивши, що кожен сеанс ASP.NET має бути заблокований за замовчуванням просто для вирішення поганого дизайну додатків, на мою думку, є поганим рішенням. Тим більше, що здається, що більшість розробників не / навіть не розуміють, що сеанси були заблоковані, не кажучи вже про те, що програми, очевидно, потрібно структурувати, щоб ви могли максимально робити стан сеансу лише для читання (відмови, де це можливо) .

Я підготував бібліотеку на основі посилань, розміщених у цій темі. Він використовує приклади MSDN та CodeProject. Завдяки Джеймсу.

Я також вносив модифікації, які радив Джоел Мюллер.

Код тут:

https://github.com/dermeister0/LockFreeSessionState

Модуль HashTable:

Install-Package Heavysoft.LockFreeSessionState.HashTable

Модуль ScaleOut StateServer:

Install-Package Heavysoft.LockFreeSessionState.Soss

Спеціальний модуль:

Install-Package Heavysoft.LockFreeSessionState.Common

Якщо ви хочете реалізувати підтримку Memcached або Redis, встановіть цей пакет. Потім успадкуйте клас LockFreeSessionStateModule та застосуйте абстрактні методи.

Код ще не випробуваний на виробництві. Також потрібно покращити обробку помилок. Винятки не вловлюються в поточній реалізації.

Деякі постачальники сеансів без блокування, що використовують Redis:

• https://github.com/angieslist/AL-Redis (Запропоновано gregmac у цій темі.)
• https://github.com/welegan/RedisSessionProvider (NuGet: RedisSessionProvider)
• https://github.com/efaruk/playground/tree/master/UnlockedStateProvider (NuGet: UnlockedStateProvider.Redis)

Якщо ваша програма не має особливих потреб, я думаю, у вас є два підходи:

1. Не використовуйте сеанс взагалі
2. Використовуйте сеанс таким, який є, і виконайте тонку настройку, як згадував Джоел.

Сесія не лише безпечна для потоків, але і безпечна для держави, таким чином, щоб ви знали, що до завершення поточного запиту кожна змінна сесія не змінюватиметься від іншого активного запиту. Для того, щоб це сталося, ви повинні переконатися, що сеанс буде ЗАКЛЮЧЕНО до завершення поточного запиту.

Ви можете створити сеанс як поведінку багатьма способами, але якщо він не блокує поточний сеанс, він не буде "сеансом".

Для конкретних проблем, які ви згадали, я думаю, ви повинні перевірити HttpContext.Current.Response.IsClientConnected . Це може бути корисно для запобігання непотрібних виконання та очікування клієнта, хоча він не може вирішити цю проблему повністю, оскільки це може використовуватися лише шляхом об'єднання, а не асинхронізацією.

Якщо ви використовуєте оновлений Microsoft.Web.RedisSessionStateProvider(починаючи з 3.0.2), ви можете додати це до свого, web.configщоб дозволити паралельні сеанси.

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

Джерело

Для ASPNET MVC ми зробили наступне:

1. За замовчуванням встановіть SessionStateBehavior.ReadOnlyусі дії контролера шляхом переосмисленняDefaultControllerFactory
2. На діях контролера, для яких потрібно записати у стан сеансу, позначте атрибут для його встановлення SessionStateBehavior.Required

Створення призначених для користувача ControllerFactory і перевизначення 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
{ }

Підключіть створену фабрику контролерів у global.asax.cs

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

Тепер ми можемо мати і те, read-onlyі read-writeстан сеансу в одному 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);
    }
}

Примітка: стан сеансу ASPNET все ще може бути записаний навіть у режимі читання, і він не викидає жодної форми винятків (він просто не блокується, щоб гарантувати послідовність), тому ми повинні бути обережними для позначення AcquireSessionLockдій контролера, які вимагають написання стану сеансу.

Позначення стану сеансу контролера як прочитаного або відключеного вирішить проблему.

Ви можете прикрасити контролер наступним атрибутом, щоб позначити його лише для читання:

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

System.Web.SessionState.SessionStateBehavior перерахування має наступні значення:

• За замовчуванням
• Інваліди
• Лише для читання
• вимагається

Просто для того, щоб допомогти будь-кому з цією проблемою (блокування запитів під час виконання іншого з того ж сеансу) ...

Сьогодні я почав вирішувати цю проблему, і через кілька годин досліджень я вирішив її, видаливши Session_Startметод (навіть якщо він порожній) з Global.asax файлу .

Це працює у всіх перевірених нами проектах.

Зупинившись на всіх доступних варіантах, я закінчив написання JWT-провайдера SessionStore на основі лексеми (сеанс перебуває всередині файлу cookie, і не потрібно зберігати резервне копіювання).

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

Переваги:

• Заміна, що змінюється, жодних змін у вашому коді не потрібно
• Масштабуйте краще, ніж будь-який інший централізований магазин, оскільки не потрібен сервер для зберігання сеансів.
• Швидше, ніж будь-яке інше сховище сеансу, оскільки жодних даних не потрібно отримувати з будь-якого сеансового сховища
• Не зберігає ресурсів сервера для зберігання сеансів.
• Неблокуюча реалізація за замовчуванням: паралельний запит не блокує один одного та не заблокує блокування на сеансі
• Горизонтально масштабуйте свою програму: оскільки дані сеансу подорожують із самим запитом, ви можете мати декілька веб-голів, не турбуючись про обмін сеансом.