Статьи

Встроенный в память SQL Server OLTP как поставщик состояния сеанса ASP.NET

Август 31, 2018

Отдельное спасибо Мэтью Вилкину за любезную помощь в рецензировании этой статьи.

Интернет-приложения используют протокол HTTP, следуя парадигме запрос-ответ. Поскольку каждый запрос не зависит от другого, нам необходимо найти способ хранения некоторой информации в нескольких запросах. Для этого либо мы помещаем все общие данные в каждый запрос, либо мы помещаем ключ (и) в запрос (ы), чтобы хранить данные на сервере для каждого ключа.

Управление состоянием является основным требованием для любого веб-приложения. Когда пользователь взаимодействует с приложением, нам необходимо поддерживать его предпочтения — состояние приложения с соответствующими действиями и ответами и, возможно, другие метаданные, связанные с приложением. Поэтому большинство каркасов веб-приложений на сегодняшний день предоставляют различные готовые функции для управления состоянием.

Управление состоянием сеанса ASP.NET

Фреймворк ASP.NET является одним из наиболее часто используемых фреймворков для создания веб-приложений. Он предоставляет широкие возможности и инструменты для быстрой разработки приложений. Сессии обычно используются в качестве метода управления состоянием во многих приложениях ASP.NET из-за их простоты и гибкости. Давайте кратко рассмотрим управление состоянием сеанса.

Диаграмма, показывающая рабочий процесс сеанса

На высоком уровне диаграмма выше показывает, что есть два типа режимов сеанса: InProc (в процессе) и OutProc (вне процесса). При использовании режима InProc данные сеанса хранятся в памяти веб-сервера, а OutProc позволяет нам хранить данные сеанса либо на сервере состояний, либо на SQL Server, либо в любом другом пользовательском месте. InProc является самым быстрым, так как данные доступны в самой памяти веб-сервера без необходимости сериализации / десериализации или ввода-вывода.

Но это не вписывается в сценарий веб-фермы / веб-сада, обычно встречающийся в корпоративных приложениях, где SQL Server используется для хранения состояния сеанса. Веб-ферма — это группа веб-серверов, на которых размещено приложение, и балансировщик нагрузки направляет запрос в зависимости от нагрузки на сервер. С другой стороны, веб-сад включает в себя несколько рабочих процессов (w3wp.exe), назначенных одним и тем же пулам приложений, которые используются хост-приложением. Оба предоставляют способ масштабирования приложения, если нагрузка на трафик не может быть обработана одним сервером или одним рабочим процессом.

Всякий раз, когда возникает необходимость в надежных сеансах, корпоративные приложения стремятся использовать функции высокой доступности, имеющиеся в SQL Server, такие как избыточность и кластеры. Однако использование SQL Server требует дополнительных затрат производительности, поскольку нам нужно сериализовать / десериализовать данные сеанса во время чтения / записи в SQL. Это требует операции ввода-вывода, поскольку данные находятся в дисковых файлах.

Данные сессий, как правило, имеют небольшой размер, но очень динамичный характер. Во времена большой нагрузки многие потоки могут записывать данные сеанса, в то время как другие читают данные. Поскольку потоки активно обращаются к данным в небольшом регионе, проблемы блокировок и блокировок начинают создавать проблемы. Чтение и запись данных начинают занимать больше времени, что создает неудобства для пользователя. Таким образом, в каждом режиме есть компромисс, но, как уже говорилось, мы используем SQL во многих сценариях и несем затраты на производительность. Для повышения производительности мы вкладываем больше долларов, добавляя в систему более мощные серверы, но выигрывают только в определенной степени, а все доступные ресурсы используются неоптимально.

Что такое OLTP в памяти?

In-Memory OLTP — это (относительно) новая технология Microsoft для обработки онлайн-транзакций, которая была введена в SQL Server 2014 для обеспечения высокопроизводительного ядра базы данных с помощью оптимизированных для памяти таблиц, которые постоянно остаются в памяти и используют собственный компилятор хранимых процедур.

Эти таблицы не страдают от фиксации, потому что механизм In-Memory OLTP использует алгоритмы и структуры без блокировок.

Microsoft начала работать над проектом с кодовым именем Hekaton, целью которого было обеспечить ядро ​​базы данных в 100 раз быстрее, чем основанное на диске. В SQL Server 2014 они представили этот новый механизм, который в 30–40 раз быстрее традиционного. Они внесли много изменений в SQL Server 2016 (который в настоящее время находится в режиме предварительного просмотра) и сделали его более надежным. Таким образом, если мы используем эту функцию SQL Server, мы можем почти снизить затраты на производительность SQL, привязанного к IO, в качестве поставщика состояния сеанса.

Использование SQL Server в памяти OLTP для управления состоянием сеанса

Для использования In-Memory OLTP мы можем написать нашего собственного провайдера. Однако через NuGet уже есть один пакет, который использует эту функцию, поэтому вместо того, чтобы использовать наш собственный, мы будем его использовать. Настройка этого пакета очень проста. Пакет NuGet можно найти на сайте NuGet или установить с помощью консоли диспетчера пакетов с 

PM> Install-Package Microsoft.Web.SessionState.SqlInMemory

Этот пакет выполняет следующие изменения в вашем приложении:

  1. Добавляет ссылку на сборку Microsoft.Web.SessionState.SqlInMemory

  2. Обновляет конфигурацию sessionState в вашем файле web.config для использования SqlInMemoryProvider: 

     <sessionState mode="Custom" customProvider="SqlInMemoryProvider"> <providers> <add name="SqlInMemoryProvider" type="Microsoft.Web.SessionState.SqlInMemoryProvider" connectionString="data source=***;initial catalog=ASPStateInMemory;User ID=user;Password=password;" /> </providers> </sessionState>

    Измените строку подключения соответственно.

  3. Предоставляет сценарий SQL с именем ASPStateInMemory.sql , который можно использовать для настройки базы данных в памяти. Перед выполнением обязательно обновите скрипт с любыми изменениями конфигурации, как указано ниже.

    а. Измените имя базы данных, которая по умолчанию называется ASPStateInMemory . замещать 

      CREATE DATABASE [ASPStateInMemory] для CREATE DATABASE <your database name>

    б. Настройте путь к основной группе базы данных.
    замещать 

      NAME = ASPStateInMemory, FILENAME 'D:\SQL\data\ASPStateInMemory_data.mdf' с NAME = ASPStateInMemory, FILENAME <path of mdf file>

    с. Измените имя файла, в котором указан путь к оптимизированной для памяти группе файлов, в соответствии с вашим собственным сервером. замещать 

      NAME = ASPStateInMemory_xtp, FILENAME = 'D:\SQL\data\ASPStateInMemory_xtp' с NAME = ASPStateInMemory_xtp, FILENAME = <path of xtp file>

    д. In-Memory OLTP предоставляет два варианта долговечности:

    • SCHEMA_ONLY : в случае перезапуска сервера таблицы будут воссозданы, а предыдущие данные будут потеряны. Это быстрее и используется, когда у нас есть временные данные. По умолчанию это включено.
    • SCHEMA_AND_DATA : в случае перезапуска сервера схема и данные сохраняются, аналогично дисковым таблицам. Чтобы настроить его, измените атрибут SCHEMA_ONLY с SCHEMA_ONLY на SCHEMA_AND_DATA .

После выполнения создается новая база данных [ASPStateInMemory] (по умолчанию) с двумя таблицами: dbo. [Sessions] и dbo. [SessionItems].

Работа с истекшими сессиями

Когда мы используем SQL для управления состоянием сеанса, нам нужно удалить данные сеанса с истекшим сроком действия. Традиционно мы использовали задание агента SQL Server для периодического удаления устаревшего сеанса.

Аналогично, здесь у нас есть новая DeleteExpiredSessions процедура DeleteExpiredSessions , которую можно настроить в задании на удаление DeleteExpiredSessions сеансов. По умолчанию время ожидания сеанса составляет 20 минут, которые можно настроить в соответствии с нашими потребностями, добавив атрибут timeout к тегу sessionState в нашем файле web.config, и каждый раз при обращении к сеансу этот тайм-аут сбрасывается.

Ключевые преимущества

In-Memory OLTP повысит производительность при использовании состояния сеанса SQL Server в 30–40 раз по сравнению с использованием традиционного состояния сеанса SQL Server. Мы также можем использовать следующие возможности SQL с использованием In-Memory OLTP:

  1. Мы можем сделать наш сеанс высокодоступным с помощью функции SQL Server AlwaysOn . Мы также можем использовать традиционный способ обеспечения высокой доступности с помощью отказоустойчивой кластеризации. Для этого нам нужно внести некоторые изменения в сценарий, например, установить долговечность SCHEMA_AND_DATA и изменить ограничение Id для таблицы SessionItems .

  2. Мы можем использовать функцию гео-избыточности SQL Server, что делает его долговечным и высокодоступным. Geo-избыточность реплицирует данные между двумя географически удаленными сайтами, так что приложения могут переключаться с одного сайта на другой. Используя это, в случае сбоя на одном сайте по какой-либо причине можно использовать другой сайт, так как на нем есть все доступные данные и конфигурация.

  3. In-Memory OLTP можно использовать в сценариях Web Farm и Web Garden.

  4. По производительности, In-Memory OLTP так же хорош, как и режим InProc .

Как продемонстрировано в недавнем тематическом исследовании (которое можно загрузить в виде документа Word с Microsoft.com ), пропускная способность приложения ASP.NET, использующего традиционный SQL Server для поддержания состояния сеанса, увеличилась в 16 раз (15000). до 250000 запросов в секунду) после миграции. Это позволило объединить множество логически разделенных серверов в один. Это не потребовало никаких изменений кода вообще.

Резюме

В этой статье рассказывается о поставщике состояния сеанса ASP.NET и его доступных параметрах, основных проблемах и о том, как каждый параметр имеет свои недостатки. В нем также рассматривался параметр In-Memory OLTP, представленный в SQL Server 2014, который можно использовать для хранения информации о состоянии сеанса.

In-Memory OLTP хранит данные в памяти сервера, использует собственный компилятор хранимых процедур и свободен от конфликтов блокировок и блокировок. Он обеспечивает производительность в 30–40 раз быстрее, чем его предшественник, и может повысить пропускную способность приложения в 16 раз после перехода в базу данных In-Memory.

Однако в SQL Server 2014 существуют ограничения, такие как размер таблиц, оптимизированных для памяти, отсутствие параллельных планов и некоторые проблемы в собственных компиляциях. Ожидается, что все они будут решены в SQL Server 2016, что сделает эту функцию более мощной и гибкой.

38
Share: