Asp не кэшируйте соединение бд в объектах application или session


Содержание

Кэш данных и объект сеанса в ASP.Net

Должны ли храниться динамические бизнес-объекты для сайта в сеансе пользователей или использовать кэширование ASP.Net(такие объекты, как заказы, информация профиля и т.д.)?

Я работал с сайтами, которые использовали сеансы для хранения бизнес-объектов, но мне было интересно. Каковы преимущества или недостатки кеширования?

Если объекты разделяются между сеансами пользователя, используйте кеш. Если объекты уникальны для каждого сеанса, возможно, потому, что они управляются разрешениями, а затем сохраняйте их в сеансе. Сам процесс in-process хранится в кеше, поэтому решающим фактором действительно должна быть область данных.

Кэширование — это просто кеширование. Вы никогда не можете опираться на записи, поэтому нет никаких предположений в этом отношении: будьте готовы перейти непосредственно к БД (или где-либо еще), чтобы восстановить данные.

С другой стороны, сеанс больше подходит для хранения объектов, хотя лично я стараюсь избегать хранения сеанса в пользу БД. Обычно я делаю это, абстрагируя хранилище за непрозрачным интерфейсом ISessionStoreService:

а затем «соответствующая реализация зависимостей», будь то InmemorySessionStore, DbSessionStore или что-то еще.

Системный кэш ASP.NET является глобальным для приложения, где сеанс уникален для текущего пользователя. Если вы решили использовать глобальный кеш для хранения объектов, вам нужно будет создать стратегию идентификации объектов, чтобы вы могли получить правильные объекты для своих пользователей.

Если вы хотите повысить производительность, вам лучше было бы заменить состояние сеанса ASP.NET кешем распределенной памяти, таким как скорость Microsoft. Microsoft опубликовала статьи о том, как заменить использование сеанса на целевую скорость. Вы также можете использовать Memcache или другие аналогичные продукты соответствующим образом.

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

Session = > Веб-страница с пошаговым интерфейсом (например, онлайн-тест).
Cache = > Информация, отображаемая в виде своего рода виджета погоды (например, того, что у Google на странице igoogle.com).
Надеюсь, это поможет.

Хотя вы можете сохранить свой бизнес-объект в кеше, но Cache предназначен для повышения производительности, а не для управления штатами. Представьте, что у вас есть процесс получения 1000 записей из базы данных (и это занимает около 3 секунд), и вам понадобится это на несколько минут. Вы можете хранить свои объекты в кеше и устанавливать дату истечения срока действия, приоритет и зависимость от него (например, SqlDependency или FileDependency), поэтому для следующих запросов вы можете использовать данные Cached вместо их извлечения из базы данных. Вы можете сохранить свой объект в сеансе, но вы не можете установить зависимость для сеанса по умолчанию. Также у Cache есть уникальное поведение, которое, когда система нуждается в памяти, будет освобождать объекты из кеша в зависимости от его приоритета. Объекты кэша являются глобальными для Приложения и распределяются между всеми пользователями, но сеанс не используется совместно и используется для каждого пользователя (сеанса).

Состояние сеанса и приложения в ASP.NET Core Session and app state in ASP.NET Core

HTTP — это протокол без отслеживания состояния. HTTP is a stateless protocol. Без дополнительных действий HTTP-запросы являются независимыми сообщениями, которые не сохраняют значения пользователя или состояние приложения. Without taking additional steps, HTTP requests are independent messages that don’t retain user values or app state. В этой статье описывается несколько подходов для сохранения данных пользователя и состояния приложения между запросами. This article describes several approaches to preserve user data and app state between requests.

Управление состоянием State management

Состояние можно сохранить несколькими способами. State can be stored using several approaches. Эти способы обсуждается ниже в данном разделе. Each approach is described later in this topic.

Способ хранения данных Storage approach Механизм хранения Storage mechanism
Файлы «cookie» Cookies Файлы cookie HTTP (могут содержать данные, сохраненные с помощью кода приложения на стороне сервера) HTTP cookies (may include data stored using server-side app code)
Состояние сеанса Session state Файлы cookie HTTP и код приложения на стороне сервера HTTP cookies and server-side app code
TempData TempData Файлы cookie HTTP или состояние сеанса HTTP cookies or session state
Строки запросов Query strings Строки запросов HTTP HTTP query strings
Скрытые поля Hidden fields Поля формы HTTP HTTP form fields
HttpContext.Items HttpContext.Items Код приложения на стороне сервера Server-side app code
Кэш Cache Код приложения на стороне сервера Server-side app code
Введение зависимостей Dependency Injection Код приложения на стороне сервера Server-side app code

Файлы cookie хранят данные между запросами. Cookies store data across requests. Так как файлы cookie отправляются с каждым запросом, их размер нужно свести к минимуму. Because cookies are sent with every request, their size should be kept to a minimum. В идеальном случае файл cookie должен содержать лишь идентификатор, а сами данные хранятся в приложении. Ideally, only an identifier should be stored in a cookie with the data stored by the app. Большинство браузеров позволяют использовать файлы cookie размером до 4096 байт. Most browsers restrict cookie size to 4096 bytes. Для каждого домена доступно лишь ограниченное число файлов cookie. Only a limited number of cookies are available for each domain.

Так как файлы cookie могут быть незаконно изменены, их нужно проверять в приложении. Because cookies are subject to tampering, they must be validated by the app. Файлы cookie могут удаляться пользователем и имеют ограниченный срок хранения на клиентах. Cookies can be deleted by users and expire on clients. Тем не менее файлы cookie обычно являются самым надежным способом хранения данных на стороне клиента. However, cookies are generally the most durable form of data persistence on the client.

Файлы cookie часто используются для персонализации, когда содержимое настраивается под известного пользователя. Cookies are often used for personalization, where content is customized for a known user. В большинстве случаев пользователь проходит только идентификацию, а не проверку подлинности. The user is only identified and not authenticated in most cases. Файл cookie может хранить имя пользователя, имя учетной записи или уникальный идентификатор пользователя (например, GUID). The cookie can store the user’s name, account name, or unique user ID (such as a GUID). Затем можно использовать файл cookie для доступа к личным настройкам пользователя, таким как цвет фона на веб-сайте. You can then use the cookie to access the user’s personalized settings, such as their preferred website background color.

Помните об Общем регламенте по защите данных в ЕС (GDPR) при создании файлов cookie и решении вопросов с конфиденциальностью. Be mindful of the European Union General Data Protection Regulations (GDPR) when issuing cookies and dealing with privacy concerns. Дополнительные сведения см. в разделе Общий регламент по защите данных (GDPR), принятый в ЕС, в ASP.NET Core. For more information, see General Data Protection Regulation (GDPR) support in ASP.NET Core.

Состояние сеанса Session state

Состояние сеанса — это сценарий ASP.NET Core для хранения пользовательских данных, когда пользователь находится в веб-приложении. Session state is an ASP.NET Core scenario for storage of user data while the user browses a web app. Состояние сеанса использует хранилище, обслуживаемое приложением, для сохранения данных между запросами от клиента. Session state uses a store maintained by the app to persist data across requests from a client. Данные сеанса поддерживаются кэшем и считаются временными, — сайт должен работать и без данных сеанса. The session data is backed by a cache and considered ephemeral data—the site should continue to function without the session data. Критически важные данные приложения должны храниться в пользовательской базе данных и кэшироваться в сеансе только в качестве оптимизации производительности. Critical application data should be stored in the user database and cached in session only as a performance optimization.

Сеанс не поддерживается в приложениях SignalR, так как хаб SignalR может выполняться независимо от контекста HTTP. Session isn’t supported in SignalR apps because a SignalR Hub may execute independent of an HTTP context. Например, это может произойти, если хаб поддерживает длительный запрос на опрос открытым, когда время существования контекста HTTP для запроса уже истекло. For example, this can occur when a long polling request is held open by a hub beyond the lifetime of the request’s HTTP context.

ASP.NET Core сохраняет состояние сеанса, предоставляя клиенту файл cookie, содержащий идентификатор сеанса, который отправляется в приложение вместе с каждым запросом. ASP.NET Core maintains session state by providing a cookie to the client that contains a session ID, which is sent to the app with each request. Приложение использует этот идентификатор для получения данных сеанса. The app uses the session ID to fetch the session data.

Состояние сеанса реагирует на события следующим образом: Session state exhibits the following behaviors:

  • Так как файл cookie сеанса относится к конкретному браузеру, обеспечить общий доступ к сеансам из разных браузеров невозможно. Because the session cookie is specific to the browser, sessions aren’t shared across browsers.
  • Файлы cookie сеанса удаляются при завершении сеанса браузера. Session cookies are deleted when the browser session ends.
  • Если получен файл cookie для просроченного сеанса, создается сеанс, использующий этот же файл. If a cookie is received for an expired session, a new session is created that uses the same session cookie.
  • Пустые сеансы не сохраняются — в сеансе должно быть хотя бы одно значение, чтобы его можно быть сохранить между запросами. Empty sessions aren’t retained—the session must have at least one value set into it to persist the session across requests. Если сеанс не сохраняется, для каждого нового запроса создается новый идентификатор сеанса. When a session isn’t retained, a new session ID is generated for each new request.
  • Приложение хранит сеанс некоторое время после последнего запроса. The app retains a session for a limited time after the last request. Приложение устанавливает время ожидания сеанса или использует значение по умолчанию, равное 20 минутам. The app either sets the session timeout or uses the default value of 20 minutes. Состояние сеанса оптимально подходит для сохранения пользовательских данных, относящихся к определенному сеансу, которые не требуется хранить бессрочно для нескольких сеансов. Session state is ideal for storing user data that’s specific to a particular session but where the data doesn’t require permanent storage across sessions.
  • Данные сеанса удаляются при вызове реализации ISession.Clear или когда истекает срок действия сеанса. Session data is deleted either when the ISession.Clear implementation is called or when the session expires.
  • Не существует механизма по умолчанию, который бы информировал код приложения о том, что браузер клиента закрыт или файл cookie сеанса удален или просрочен на клиенте. There’s no default mechanism to inform app code that a client browser has been closed or when the session cookie is deleted or expired on the client.
  • Шаблоны ASP.NET Core MVC и Razor Pages поддерживают общий регламент по защите данных (GDPR). The ASP.NET Core MVC and Razor pages templates include support for General Data Protection Regulation (GDPR). Файлы cookie для состояния сеанса не помечаются как основные по умолчанию, поэтому состояние сеанса недоступно, если отслеживание разрешено посетителем сайта. Session state cookies aren’t marked essential by default, so session state isn’t functional unless tracking is permitted by the site visitor. Дополнительные сведения можно найти по адресу: Поддержка Общий регламент по защите данных (GDPR) в ASP.NET Core. For more information, see Поддержка Общий регламент по защите данных (GDPR) в ASP.NET Core.

Не храните конфиденциальные данные в состоянии сеанса. Don’t store sensitive data in session state. Пользователь может не закрывать браузер и очистить файл cookie сеанса. The user might not close the browser and clear the session cookie. Некоторые браузеры сохраняют файлы cookie сеанса в нескольких окнах браузера. Some browsers maintain valid session cookies across browser windows. Сеанс может быть не ограничен одним пользователем — следующий пользователь продолжит использовать приложение с тем же файлом cookie сеанса. A session might not be restricted to a single user—the next user might continue to browse the app with the same session cookie.

Поставщик кэша в памяти хранит данные сеанса в памяти сервера, содержащего приложение. The in-memory cache provider stores session data in the memory of the server where the app resides. В сценарии с фермой серверов: In a server farm scenario:

  • Используйте прикрепленные сеансы для привязки сеанса к конкретному экземпляру приложения на отдельном сервере. Use sticky sessions to tie each session to a specific app instance on an individual server. Служба приложений Azure использует маршрутизацию запросов приложений (ARR), чтобы прикрепленные сеансы создавались по умолчанию. Azure App Service uses Application Request Routing (ARR) to enforce sticky sessions by default. Однако прикрепленные сеансы могут негативно повлиять на масштабируемость и усложнить обновление веб-приложений. However, sticky sessions can affect scalability and complicate web app updates. Лучше использовать распределенные кэши SQL Server или Redis, для которых прикрепленные сеансы не требуются. A better approach is to use a Redis or SQL Server distributed cache, which doesn’t require sticky sessions. Дополнительные сведения можно найти по адресу: Распределенное кэширование в ASP.NET Core. For more information, see Распределенное кэширование в ASP.NET Core.
  • Файл cookie сеанса шифруется через IDataProtector. The session cookie is encrypted via IDataProtector. Необходимо правильно настроить защиту данных, чтобы читать файлы cookie сеанса на каждом компьютере. Data Protection must be properly configured to read session cookies on each machine. Дополнительные сведения см. статьях Защита данных в ASP.NET Core и Key storage providers in ASP.NET Core (Поставщики хранилища ключей в ASP.NET Core). For more information, see Защита данных в ASP.NET Core and Key storage providers.

Настройка состояния сеанса Configure session state

Пакет Microsoft.AspNetCore.Session, который входит в метапакет Microsoft.AspNetCore.App, предоставляет ПО промежуточного слоя для управления состоянием сеанса. The Microsoft.AspNetCore.Session package, which is included in the Microsoft.AspNetCore.App metapackage, provides middleware for managing session state. Чтобы включить сеанс ПО промежуточного слоя для сеансов, Startup должен содержать: To enable the session middleware, Startup must contain:

  • Любой из кэшей памяти IDistributedCache, Any of the IDistributedCache memory caches. при этом реализация IDistributedCache используется в качестве резервного хранилища для сеанса. The IDistributedCache implementation is used as a backing store for session. Дополнительные сведения можно найти по адресу: Распределенное кэширование в ASP.NET Core. For more information, see Распределенное кэширование в ASP.NET Core.
  • Вызов AddSession в ConfigureServices . A call to AddSession in ConfigureServices .
  • Вызов UseSession в Configure . A call to UseSession in Configure .

Следующий код показывает, как настроить поставщик сеансов в памяти с реализацией в памяти IDistributedCache по умолчанию: The following code shows how to set up the in-memory session provider with a default in-memory implementation of IDistributedCache :

Порядок ПО промежуточного слоя важен. The order of middleware is important. В предыдущем примере исключение InvalidOperationException возникает при вызове UseSession после UseMvc . In the preceding example, an InvalidOperationException exception occurs when UseSession is invoked after UseMvc . Дополнительные сведения см. в разделе Порядок расположения ПО промежуточного слоя. For more information, see Middleware Ordering.

После настройки состояния сеанса доступно свойство HttpContext.Session. HttpContext.Session is available after session state is configured.

Невозможно получить доступ к HttpContext.Session до вызова UseSession . HttpContext.Session can’t be accessed before UseSession has been called.

Невозможно создать новый сеанс с новым файлом cookie сеанса после того, как приложение начинает запись в поток ответа. A new session with a new session cookie can’t be created after the app has begun writing to the response stream. Исключение записывается в журнал веб-сервера и не отображается в браузере. The exception is recorded in the web server log and not displayed in the browser.

Асинхронная загрузка состояния сеанса Load session state asynchronously

Поставщик сеансов по умолчанию в ASP.NET Core загружает запись сеанса из резервного хранилища IDistributedCache в асинхронном режиме только при явном вызове метода ISession.LoadAsync перед методами TryGetValue, Set или Remove. The default session provider in ASP.NET Core loads session records from the underlying IDistributedCache backing store asynchronously only if the ISession.LoadAsync method is explicitly called before the TryGetValue, Set, or Remove methods. Если LoadAsync не вызывается первым, базовая запись сеанса загружается синхронно, что может негативно повлиять на производительность. If LoadAsync isn’t called first, the underlying session record is loaded synchronously, which can incur a performance penalty at scale.

Чтобы принудительно использовать этот режим в приложениях, используйте для реализаций DistributedSessionStore и DistributedSession оболочку из версий, которые выдают исключение, когда метод LoadAsync не вызывается перед TryGetValue , Set или Remove . To have apps enforce this pattern, wrap the DistributedSessionStore and DistributedSession implementations with versions that throw an exception if the LoadAsync method isn’t called before TryGetValue , Set , or Remove . Зарегистрируйте версии оболочки в контейнере служб. Register the wrapped versions in the services container.

Параметры сеанса Session options

Чтобы переопределить значения по умолчанию для сеанса, используйте SessionOptions. To override session defaults, use SessionOptions.

Параметр Option ОПИСАНИЕ Description
Файл cookie Cookie Определяет параметры, используемые для создания файлов cookie. Determines the settings used to create the cookie. Параметр Name по умолчанию имеет значение SessionDefaults.CookieName ( .AspNetCore.Session ). Name defaults to SessionDefaults.CookieName ( .AspNetCore.Session ). Параметр Path по умолчанию имеет значение SessionDefaults.CookiePath ( / ). Path defaults to SessionDefaults.CookiePath ( / ). Параметр SameSite по умолчанию имеет значение SameSiteMode.Lax ( 1 ). SameSite defaults to SameSiteMode.Lax ( 1 ). Параметр HttpOnly по умолчанию имеет значение true . HttpOnly defaults to true . Параметр IsEssential по умолчанию имеет значение false . IsEssential defaults to false .
IdleTimeout IdleTimeout IdleTimeout указывает, как долго сеанс может быть неактивным, прежде чем его содержимое отбрасывается. The IdleTimeout indicates how long the session can be idle before its contents are abandoned. Каждый доступ к сеансу сбрасывает время ожидания. Each session access resets the timeout. Этот параметр применяется только к содержимому сеанса, а не к файлу cookie. This setting only applies to the content of the session, not the cookie. Значение по умолчанию — 20 минут. The default is 20 minutes.
IOTimeout IOTimeout Максимальный период загрузки сеанса из хранилища или его сохранения обратно в хранилище. The maximum amount of time allowed to load a session from the store or to commit it back to the store. Этот параметр может применяться только к асинхронным операциям. This setting may only apply to asynchronous operations. Время ожидания можно отключить с помощью InfiniteTimeSpan. This timeout can be disabled using InfiniteTimeSpan. Значение по умолчанию — 1 минута. The default is 1 minute.

Сеанс использует файл cookie для отслеживания и идентификации запросов в одном браузере. Session uses a cookie to track and identify requests from a single browser. По умолчанию этот файл cookie называется .AspNetCore.Session и использует путь / . By default, this cookie is named .AspNetCore.Session , and it uses a path of / . Так как по умолчанию файл cookie не указывает домен, он остается недоступным для клиентского сценария на странице (так как HttpOnly по умолчанию имеет значение true ). Because the cookie default doesn’t specify a domain, it isn’t made available to the client-side script on the page (because HttpOnly defaults to true ).

Чтобы переопределить файл cookie по умолчанию для сеанса, используйте SessionOptions : To override cookie session defaults, use SessionOptions :

Приложение использует свойство IdleTimeout, чтобы определить, как долго сеанс может оставаться неактивным до сброса его содержимого в кэше сервера. The app uses the IdleTimeout property to determine how long a session can be idle before its contents in the server’s cache are abandoned. Это свойство не зависит от срока действия файла cookie. This property is independent of the cookie expiration. Каждый запрос, проходящий через ПО промежуточного слоя сеанса, сбрасывает это время ожидания. Each request that passes through the Session Middleware resets the timeout.

Состояние сеанса является неблокирующим. Session state is non-locking. Когда два запроса пытаются изменить содержимое сеанса, последний из них переопределяет первый. If two requests simultaneously attempt to modify the contents of a session, the last request overrides the first. Session реализован в виде согласованного сеанса, что означает, что все содержимое хранится вместе. Session is implemented as a coherent session, which means that all the contents are stored together. Когда два запроса пытаются изменить разные значения сеанса, последний запрос может переопределить изменения, внесенные первым. When two requests seek to modify different session values, the last request may override session changes made by the first.

Установка и получение значений сеанса Set and get Session values

Получить доступ к состоянию сеанса можно через класс Razor Pages PageModel или класс MVC Controller со свойством HttpContext.Session. Session state is accessed from a Razor Pages PageModel class or MVC Controller class with HttpContext.Session. Оно является реализацией ISession. This property is an ISession implementation.

Реализация ISession предоставляет несколько методов расширения для задания и извлечения значений типа integer и string. The ISession implementation provides several extension methods to set and retrieve integer and string values. Методы расширения находятся в пространстве имен Microsoft.AspNetCore.Http (добавьте оператор using Microsoft.AspNetCore.Http; , чтобы получить доступ к методам расширения), когда проект ссылается на пакет Microsoft.AspNetCore.Http.Extensions. The extension methods are in the Microsoft.AspNetCore.Http namespace (add a using Microsoft.AspNetCore.Http; statement to gain access to the extension methods) when the Microsoft.AspNetCore.Http.Extensions package is referenced by the project. Оба пакета входят в метапакет Microsoft.AspNetCore.App. Both packages are included in the Microsoft.AspNetCore.App metapackage.

Методы расширения ISession : ISession extension methods:

В следующем примере извлекается значение сеанса для ключа IndexModel.SessionKeyName ( _Name в примере приложения) на странице Razor Pages: The following example retrieves the session value for the IndexModel.SessionKeyName key ( _Name in the sample app) in a Razor Pages page:

В следующем примере показано, как задать, а затем получить значения integer и string: The following example shows how to set and get an integer and a string:

Все данные сеанса должны быть сериализованы, чтобы использовать сценарий-распределенного кэша даже при использовании кэша в памяти. All session data must be serialized to enable a distributed cache scenario, even when using the in-memory cache. Предоставляются минимальные сериализаторы строки и числа (см. методы и методы расширения ISession). Minimal string and number serializers are provided (see the methods and extension methods of ISession). Сложные типы должны быть сериализованы пользователем с помощью другого механизма, например JSON. Complex types must be serialized by the user using another mechanism, such as JSON.

Добавьте приведенные ниже методы расширения, чтобы задавать и получать сериализуемые объекты: Add the following extension methods to set and get serializable objects:

Следующий пример показывает, как задать и получить сериализуемый объект с помощью методов расширения: The following example shows how to set and get a serializable object with the extension methods:

TempData TempData

ASP.NET Core предоставляет TempData Razor Pages или TempData контроллера. ASP.NET Core exposes the Razor Pages TempData or Controller TempData. Это свойство хранит данные до тех пор, пока они не будут прочитаны в другом запросе. This property stores data until it’s read in another request. Для проверки данных без удаления можно использовать методы Keep(String) и Peek(String) в конце запроса. Keep(String) and Peek(string) methods can be used to examine the data without deletion at the end of the request. Keep() помечает все элементы в словаре для хранения. Keep() marks all items in the dictionary for retention. TempData особенно удобно использовать для перенаправления, когда данные требуются для нескольких запросов. TempData is particularly useful for redirection when data is required for more than a single request. TempData реализуется поставщиками TempData , например, с помощью файлов cookie или состояния сеанса. TempData is implemented by TempData providers using either cookies or session state.

Примеры TempData TempData samples

Рассмотрим следующую страницу, которая создает клиент: Consider the following page that creates a customer:

На следующей странице отображается TempData[«Message»] : The following page displays TempData[«Message»] :

В предыдущей разметке в конце запроса TempData[«Message»] не удаляется, так как используется Peek . In the preceding markup, at the end of the request, TempData[«Message»] is not deleted because Peek is used. На обновляемой странице отображается TempData[«Message»] . Refreshing the page displays TempData[«Message»] .

Следующая разметка похожа на приведенный выше код, но в ней используется Keep для сохранения данных в конце запроса: The following markup is similar to the preceding code, but uses Keep to preserve the data at the end of the request:

При переходе между страницами IndexPeek и IndexKeep TempData[«Message»] не удаляется. Navigating between the IndexPeek and IndexKeep pages won’t delete TempData[«Message»] .

Следующий код отображает TempData[«Message»] , но в конце запроса TempData[«Message»] удаляется: The following code displays TempData[«Message»] , but at the end of the request, TempData[«Message»] is deleted:

Поставщики TempData TempData providers

Поставщик TempData, основанный на файлах cookie, используется по умолчанию для хранения TempData в файлах cookie. The cookie-based TempData provider is used by default to store TempData in cookies.

Данные в файле cookie шифруются с помощью IDataProtector, кодируются с помощью Base64UrlTextEncoder, а затем фрагментируются. The cookie data is encrypted using IDataProtector, encoded with Base64UrlTextEncoder, then chunked. Так как файл cookie фрагментируется, ограничение на размер одного такого файла, заданное в ASP.NET Core 1.x, не применяется. Because the cookie is chunked, the single cookie size limit found in ASP.NET Core 1.x doesn’t apply. Данные файла cookie не сжимаются, так как сжатие зашифрованных данных может привести к проблемам с безопасностью, например атакам CRIME и BREACH. The cookie data isn’t compressed because compressing encrypted data can lead to security problems such as the CRIME and BREACH attacks. Дополнительные сведения на поставщике TempData, основанном на файлах cookie, см. в разделе CookieTempDataProvider. For more information on the cookie-based TempData provider, see CookieTempDataProvider.

Выбор поставщика TempData Choose a TempData provider

Выбор поставщика TempData включает в себя несколько аспектов: Choosing a TempData provider involves several considerations, such as:


  1. Приложение уже использует состояние сеанса? Does the app already use session state? Если это так, использование поставщика TempData для состояния сеанса не требует от приложения никаких дополнительных издержек (кроме объема данных). If so, using the session state TempData provider has no additional cost to the app (aside from the size of the data).
  2. Приложение использует TempData лишь ограниченно, для сравнительно небольших объемов данных (до 500 байт)? Does the app use TempData only sparingly for relatively small amounts of data (up to 500 bytes)? Если это так, поставщик TempData на основе файлов cookie незначительно увеличивает издержки для каждого запроса, переносящего TempData. If so, the cookie TempData provider adds a small cost to each request that carries TempData. В противном случае поставщик TempData для состояния сеанса удобно использовать, чтобы устранить круговой обход большого объема данных в каждом запросе до полного использования TempData. If not, the session state TempData provider can be beneficial to avoid round-tripping a large amount of data in each request until the TempData is consumed.
  3. Приложение выполняется на ферме серверов на нескольких серверах? Does the app run in a server farm on multiple servers? Если это так, не требуется дополнительная настройка для использования поставщика TempData для файлов cookie, за исключением защиты данных (см. статьи Защита данных в ASP.NET Core и Key storage providers in ASP.NET Core (Поставщики хранилища ключей в ASP.NET Core)). If so, there’s no additional configuration required to use the cookie TempData provider outside of Data Protection (see Защита данных в ASP.NET Core and Key storage providers).

Большинство веб-клиентов (например, веб-браузеры) налагают ограничение на максимальный размер каждого файла cookie и (или) общее количество таких файлов. Most web clients (such as web browsers) enforce limits on the maximum size of each cookie, the total number of cookies, or both. При использовании поставщика TempData на основе файлов cookie убедитесь, что приложение не нарушает эти ограничения. When using the cookie TempData provider, verify the app won’t exceed these limits. Учитывайте общий объем данных. Consider the total size of the data. Учитывайте увеличение размеров файла cookie в результате шифрования и фрагментирования. Account for increases in cookie size due to encryption and chunking.

Настройка поставщика TempData Configure the TempData provider

Поставщик TempData на основе файлов cookie включен по умолчанию. The cookie-based TempData provider is enabled by default.

Чтобы включить поставщик TempData на основе сеанса, используйте метод расширения AddSessionStateTempDataProvider: To enable the session-based TempData provider, use the AddSessionStateTempDataProvider extension method:

Порядок ПО промежуточного слоя важен. The order of middleware is important. В предыдущем примере исключение InvalidOperationException возникает при вызове UseSession после UseMvc . In the preceding example, an InvalidOperationException exception occurs when UseSession is invoked after UseMvc . Дополнительные сведения см. в разделе Порядок расположения ПО промежуточного слоя. For more information, see Middleware Ordering.

Если вы ориентируетесь на .NET Framework и используете поставщик TempData на основе сеансов, добавьте в проект пакет Microsoft.AspNetCore.Session. If targeting .NET Framework and using the session-based TempData provider, add the Microsoft.AspNetCore.Session package to the project.

Строки запроса Query strings

Вы можете передать ограниченный объем данных из одного запроса в другой, добавив их в строку запроса нового запроса. A limited amount of data can be passed from one request to another by adding it to the new request’s query string. Это удобно для захвата состояния в сохраняемом виде, что позволяет обмениваться ссылками с внедренным состоянием по электронной почте или через социальные сети. This is useful for capturing state in a persistent manner that allows links with embedded state to be shared through email or social networks. Поскольку строки запроса URL-адреса являются открытыми, никогда не используйте их для конфиденциальных данных. Because URL query strings are public, never use query strings for sensitive data.

Вдобавок к случайному раскрытию информации включение данных в строки запроса может открыть возможности для атак с подделкой межсайтовых запросов (CSRF), которые могут обманом вынудить пользователей посещать вредоносные веб-сайты во время проверки подлинности. In addition to unintended sharing, including data in query strings can create opportunities for Cross-Site Request Forgery (CSRF) attacks, which can trick users into visiting malicious sites while authenticated. Это позволит злоумышленникам похитить данные пользователей из приложения или предпринимать вредоносные действия от их имени. Attackers can then steal user data from the app or take malicious actions on behalf of the user. Любое сохраненное состояние приложения или сеанса необходимо защитить от атак CSRF. Any preserved app or session state must protect against CSRF attacks. Дополнительные сведения см. в статье Предотвращение атак с подделкой межсайтовых запросов (XSRF/CSRF). For more information, see Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks.

Скрытые поля Hidden fields

Данные можно сохранить в скрытых полях формы и опубликовать обратно при следующем запросе. Data can be saved in hidden form fields and posted back on the next request. Это типичное поведение для многостраничных форм. This is common in multi-page forms. Так как клиент может незаконно изменить данные, приложение всегда должно перепроверять данные в скрытых полях. Because the client can potentially tamper with the data, the app must always revalidate the data stored in hidden fields.

HttpContext.Items HttpContext.Items

Коллекция HttpContext.Items используется для хранения данных при обработке одного запроса. The HttpContext.Items collection is used to store data while processing a single request. Ее содержимое удаляется после обработки каждого запроса. The collection’s contents are discarded after a request is processed. Коллекцию Items часто используют для обеспечения взаимодействия компонентов или ПО промежуточного слоя, когда они выполняются в разные моменты времени во время обработки запроса и не могут передавать параметры напрямую. The Items collection is often used to allow components or middleware to communicate when they operate at different points in time during a request and have no direct way to pass parameters.

В следующем примере ПО промежуточного слоя добавляет isVerified в коллекцию Items . In the following example, middleware adds isVerified to the Items collection.

Далее в конвейере другое ПО промежуточного слоя может получить доступ к значению isVerified : Later in the pipeline, another middleware can access the value of isVerified :

Для ПО промежуточного слоя, которое используется всего одним приложением, допустимы ключи string . For middleware that’s only used by a single app, string keys are acceptable. ПО промежуточного слоя, используемое несколькими экземплярами приложения, должно использовать уникальные ключи объекта во избежание конфликтов. Middleware shared between app instances should use unique object keys to avoid key collisions. В следующем примере показано, как использовать уникальный ключ объекта, определенный в классе ПО промежуточного слоя: The following example shows how to use a unique object key defined in a middleware class:

Другой код может обратиться к значению, хранящемуся в HttpContext.Items , с помощью ключа, предоставляемого классом ПО промежуточного слоя: Other code can access the value stored in HttpContext.Items using the key exposed by the middleware class:

Данный подход также позволяет не использовать строки ключей в коде. This approach also has the advantage of eliminating the use of key strings in the code.

Кэш Cache

Кэширование — это эффективный способ хранения и извлечения данных. Caching is an efficient way to store and retrieve data. Приложение может управлять временем существования элементов кэша. The app can control the lifetime of cached items.

Кэшированные данные не связаны с конкретным запросом, пользователем или сеансом. Cached data isn’t associated with a specific request, user, or session. Будьте внимательны и не кэшируйте данные пользователя, которые можно извлечь по запросу другого пользователя. Be careful not to cache user-specific data that may be retrieved by other users’ requests.

Дополнительные сведения можно найти по адресу: Кэширование ответов в ASP.NET Core. For more information, see Кэширование ответов в ASP.NET Core.

Внедрение зависимостей Dependency Injection

Используйте внедрение зависимостей, чтобы сделать данные доступными для всех пользователей: Use Dependency Injection to make data available to all users:

Определите службу, содержащую данные. Define a service containing the data. Например, определяется класс с именем MyAppData : For example, a class named MyAppData is defined:

Добавьте класс службы в Startup.ConfigureServices : Add the service class to Startup.ConfigureServices :

Используйте класс службы данных: Consume the data service class:

Распространенные ошибки Common errors

«Unable to resolve service for type «Microsoft.Extensions.Caching.Distributed.IDistributedCache» while attempting to activate «Microsoft.AspNetCore.Session.DistributedSessionStore»» (Не удается разрешить службу для типа «Microsoft.Extensions.Caching.Distributed.IDistributedCache» при попытке активировать «Microsoft.AspNetCore.Session.DistributedSessionStore»). «Unable to resolve service for type ‘Microsoft.Extensions.Caching.Distributed.IDistributedCache’ while attempting to activate ‘Microsoft.AspNetCore.Session.DistributedSessionStore’.»

Обычно она вызвана невозможностью настройки по меньшей мере одной реализации IDistributedCache . This is usually caused by failing to configure at least one IDistributedCache implementation. Дополнительные сведения см. в разделах Распределенное кэширование в ASP.NET Core и Кэширование в памяти в ASP.NET Core. For more information, see Распределенное кэширование в ASP.NET Core and Кэширование в памяти в ASP.NET Core.

Если ПО промежуточного слоя для сеанса не удается сохранить сеанс (например, резервное хранилище недоступно), оно регистрирует исключение и запрос выполняется обычным образом. In the event that the session middleware fails to persist a session (for example, if the backing store isn’t available), the middleware logs the exception and the request continues normally. Это приводит к непредсказуемому поведению. This leads to unpredictable behavior.

Например, пользователь сохраняет корзину для покупок в сеансе. For example, a user stores a shopping cart in session. Он добавляет товар в корзину, но фиксация завершается сбоем. The user adds an item to the cart but the commit fails. Приложению неизвестно о сбое, поэтому оно сообщает пользователю, что товар добавлен в корзину, хотя это не так. The app doesn’t know about the failure so it reports to the user that the item was added to their cart, which isn’t true.

Какие преимущества хранения сессий в бд?

Пару человек сказало, что хранение сессий в бд, это наилучший вариант( если нужно длительное хранение сессий ), в чем преимущество?
мне ответили в гибкости, но где работа с сессиями становится более гибкой, мне непонятно.

Подскажите пожалуйста, в чем + и —

  • Вопрос задан более трёх лет назад
  • 3311 просмотров

Сессию в базе хранят на тот случай, если там есть что-то ценное.
Например, есть конструктор сайтов или социальная сеть. И пользователь может кое-что сделать ещё до регистрации, например, создать пост или профиль свой заполнить. Можно все его временные данные сериализовать и поместить в базу, чаще всего JSON в NoSQL.
В обычную сессию тоже можно сохранить, но обычно пространство для хранения сессий регулярно чистят и тогда данные потеряются.
Сохранять в базу стоит только тогда, когда пользователь сделал что-то. Для каждого пользователя выделять место в базе бессмысленно.
Когда пользователь авторизуется, временные данные переносят на постоянное место хранения.
Регулярно область сессий неавторизованных пользователей чистят, но гуманно, то есть не очень активно, с большим интервалом хранения.

Я обычно с другим сталкивался — данные из базы выгружают в сессию, чтобы меньше нагружать базу.
Вот схема: https://toster.ru/answer?answer_ >

Ну для системы авторизации, лучше хранить сессию в бд или на файлах?

Думаю на файлах, потому что информации не много и лишние обращения к бд не к чему и т.д

Нет преимуществ. Ваша пара человек не понимает о чем говорит.

Для начала потому что сессий у одного пользователя может быть множество, и это вполне нормально. Залогиньтесь в двух браузерах одним пользователем например.

Сессия как правило — это необходимые горячие данные пользователя, что нужно сохранить между запросами. БД — одно из самых медленных хранилищ этих данных.

В файлах кстати тоже не стоит хранить. При большой нагрузке io будет подтормаживать.

Длительный период сессии обычно не хранятся, вместо этого на клиент задается токен, по которому человек через много времени может автоматически авторизироваться.

Длительный период сессии обычно не хранятся, вместо этого на клиент задается токен, по которому человек через много времени может автоматически авторизироваться.

Не совсем понял, можно по подробнее или где об этом почитать можно?

У меня система авторизации на сессиях( не на кукисах, потому что нужно иметь возможность разлогинить пользователя без его участия и т.п )

И для того, чтобы каждый раз не приходилось вводить логин/пароль, продлил время жизни сессии и храню её в директории сайта

> не на кукисах, потому что нужно иметь возможность разлогинить пользователя без его участия и т.п
Ключ к сессии — это кука.

Смысл автологина полностью аналогичный. Есть постоянная кука, передаваемая на фронт, просто в случае если сессия не создана — проверяется связь вот этот куки с пользовательским профилем, если такая имеется — нужно авторизовать пользователя.

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

Еще удобно связывать сессию с конкретным юзером в БД. Можно вводить ограничения типа «нельзя быть залогиненым с двух браузеров», удобно для онлайн игр.

Или дать функционал «Разлогинить меня на всех устройствах».

Использование баз данных в приложениях ASP.NET

Организация взаимодействия с БД

Для того, чтобы приложение . NET могло осуществлять взаимодействие с источником данных, необходимо установить соединение с ним. Наиболее типичным сценарием работы Web -приложения является следующий:

  1. Устанавливается соединение, открывается подключение к базе данных .
  2. Выполняется один или несколько запросов, осуществляющих внесение изменений в наборы данных источника данных, а также выборку данных из БД.
  3. Осуществляется отключение от источника данных. При этом пользователь работает с отсоединенным набором данных, просматривая его, выполняя фильтрацию, внося изменения и т. д.
  4. При необходимости переноса изменений из отсоединенного набора данных в БД, а также при необходимости просмотра изменений, внесенных в БД другими пользователями, осуществляется подключение к источнику данных, выполняются необходимые действия, после чего производится отключение от БД.

Рассмотрим эти этапы более подробно.

Подключение к БД

Как уже говорилось выше, для подключения к источнику данных с использованием ADO.NET необходимо воспользоваться объектом Connection. Для рассмотрения примеров подключений к источникам данных прежде всего необходимо выбрать поставщика данных, с которым будет работать приложение. Затем необходимо подключить соответствующие пространства имен, содержащие определения объектов выбранного поставщика. В качестве примеров подключения к источникам данных будем рассматривать базы данных Access и SQL Server 2005 Express Edition. Такой выбор продиктован прежде всего тем, что Access очень хорошо подходит для построения небольших информационных систем, нетребователен к ресурсам компьютера, не требует установки специального программного обеспечения. SQL Server Express является свободно распространяемой СУБД, обладающей всеми достоинствами коммерческого SQL Server 2005 и имеющей ряд ограничений, в том числе на максимальный объем базы данных (не более 4 Гб). Все приемы работы с базами данных, описываемые ниже, могут быть использованы также для работы с коммерческими версиями продуктов Microsoft и другими СУБД.

Итак, для того, чтобы подключиться к базе данных во время выполнения программы, необходимо создать объект Connection, а также задать его свойства, определяющие текущие параметры подключения. Основным параметром, устанавливающим необходимые опции для подключения к БД, является строка соединения , которая представляет собой набор пар «имя-значение», разделенных точкой с запятой. Порядок следования значений этих параметров, а также их регистр не важны. Строка соединения зависит от СУБД, к которой осуществляется подключение, а также от используемого поставщика данных. Тем не менее существует несколько фрагментов информации, указываемой в строке подключения, которые необходимы практически всегда. Перечислим их и прокомментируем их назначение.

  1. Сервер, на котором находится база данных. Если СУБД, к которой осуществляется подключение, расположена на клиентском компьютере (так будет во всех примерах, рассматриваемых в рамках данного курса), то вместо имени сервера необходимо указывать имя localhost либо IP-адрес 127.0.0.1.

  2. Имя базы данных, к которой производится подключение.
  3. Способ аутентификации пользователя. Существующие клиент-серверные СУБД (к которым относится SQL Server, Oracle и ряд других) позволяют указывать в строке подключения имя пользователя и пароль, которые будут нужны для проверки возможности доступа к базе данных, либо использовать параметры текущего пользователя.

В качестве примера рассмотрим создание небольшого Web-приложения для работы с базой данных, ER-модель которой представлена на рис. 10.3.

Создадим базы данных в соответствии с моделью, изображенной на рис. 10.3, в формате SQL Server Express и Access 2003. Для этого исполним следующие SQL-запросы :

Построение Web-приложений для работы с базами данных различных видов практически идентичны. Основное различие заключается в способе организации доступа к самой базе, т. е. в способе подключения к ней. Для подключения к БД используется объект Connection из пространства имен System.Data.SqlClient в случае с SQL Server и System.Data.OleDb — в случае с другими источниками данных, например, Access. Строки соединения с базами данных при этом будут выглядеть следующим образом:

Для открытия соединения с базой данных необходимо вызвать метод Open объекта Connection . При этом строку соединения с БД можно передать как в качестве параметра конструктора объекта, так и потом с помощью установки соответствующего свойства.

Строку соединения с базой данных можно жестко прописать в исходном коде приложения, однако это не самый лучший вариант, т. к. при изменении пути к базе данных либо других параметров соединения придется вносить изменения в исходный код приложения и перекомпилировать его. В связи с этим лучше всего использовать строку соединения, сохраненную в файле web.config .

Впоследствии эту строку можно извлечь из файла web.config .

Управление соединением осуществляется очень легко. Методы Open и Close объекта Connection выполняют всю работу. Однако следует учитывать, что при подключении к базе данных может произойти сбой, в результате которого установить соединение с ней окажется невозможно. Это может быть особенно актуальным при размещении базы данных на другом сервере, который в момент подключения может оказаться недоступным. Для того чтобы неудавшаяся попытка соединения с базой данных не приводила к фатальным последствиям при работе приложения, необходимо использовать конструкции try catch , позволяющие адекватно реагировать на возникшую ошибку. Следующий пример демонстрирует возможность использования такого подхода.

Результатом работы этого фрагмента кода в случае успешного установления соединения будет сообщение, изображенное на рис. 10.5.

На рис. 10.6 изображено окно, содержащее сообщение об ошибке установления соединения.

Для обслуживания соединения с базой данных расходуются ресурсы компьютера, на котором выполняется Web-приложение. В связи с этим рекомендуется открывать соединение как можно позже, а закрывать как можно раньше, сразу после того, как все необходимые действия с объектами базы данных были выполнены. Кроме того, желательно строить программный код так, чтобы соединение с базой данных закрывалось при любом исходе соединения с ней. В предыдущем примере код, расположенный в блоке finally , выполнится при любом исходе попытки подключения, что гарантирует освобождение ресурсов сервера, не дожидаясь момента, когда память будет освобождена сборщиком мусора.

HTTP сессия. Session. Состояние сеанса. Работа с сессиями в ASP.NET MVC

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

Прежде чем мы дадим определение термину «сессия», давайте немного рассмотрим предысторию, зачем вообще возникла потребность в сессиях, рассмотрим одну особенность протокола HTTP.

Одной из основных особенностей протокола HTTP является то, что он не обязывает сервер сохранять информацию о клиенте между запросами, то есть идентифицировать клиента. Это так называемый stateless-протокол. Связь между клиентом и сервером заканчивается как только завершается обработка текущего запроса. Каждый новый запрос к серверу подразумевается как абсолютно уникальный и независимый, даже если он был отправлен повторно от одного и того же источника.

Что, если оставить stateless-природу протокола HTTP и не идентифицировать пользователя? Без состояний сеанса можно легко обойтись, если на вашем сайте представлена статичная (обезличенная) информация, например, новостная статья, состоящая из текста и изображений. В таком контексте совершенно необязательно ассоциировать несколько запросов с одним пользователем. Ведь содержание статьи никак не изменится, будь то десять запросов с одного устройства, либо десять запросов от разных людей с разных устройств.

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

Вот как раз в таких ситуациях, когда требуется персонализировать запросы от одного клиента, мы будем использовать сессии.

Когда клиент впервые передает персональные данные в запросе, на сервере создается новая сессия для этого клиента. В период времени жизни сессии все запросы от этого клиента будут однозначно распознаны и связаны с ним. По истечении этого времени связь с клиентом будет потеряна, и очередной запрос от него будет обрабатываться как абсолютно уникальный, никак не связанный с предыдущими.

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

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

  1. скрытые поля на HTML-форме (hidden form fields)
  2. куки (cookies)
  3. сессия (session, session State)

Попробуем их реализовать, используя платформу ASP.NET. Давайте кратко рассмотрим первые два механизма, и особое внимание уделим третьему, как более надежному, удобному и безопасному.

Скрытые поля на HTML-форме (hidden form fields)

Суть данного подхода состоит в том, что мы обеспечиваем навигацию по сайту при помощи стандартных html-форм. И при каждом следующем запросе мы сохраняем данные из предыдущего в скрытых полях на форме. Например:

В данном примере мы на первой html-форме получаем имя пользователя. Далее в контроллере в методе Forms2() мы извлекаем это значение из коллекции Form и передаем в представление посредством объекта ViewBag. В этом представлении генерируется код новой формы и в скрытом поле сохраняется имя пользователя. Таким образом, значение имени пользователя будет передано уже на третью формы вместе с дополнительной информацией — значением поля с именем «foodName». И так далее.

Давайте рассмотрим особенности такого подхода. Плюсов практически нет, разве что реализовать данную технику можно очень быстро. Но опять же и другие подходы тоже можно реализовать очень быстро. А вот минусы есть, и довольно существенные:

  • Во-первых, этот вариант не будет работать, если html-формы на наших страницах статичны, то есть жестко закодированы. И чтобы это исправить, чтобы повлиять на html-разметку мы прибегаем к помощи какой-нибудь серверной технологии (в данном случае механизм ViewBag);
  • Это безопасность. Хоть вводимые нами данные не передаются через url-параметры в адресной строке и визуально не видны на странице, мы с легкостью можем их получить или подменить или удалить или украсть просто изучив исходный код страницы или структуру запроса;

Куки (cookies)

В данном подходе мы не храним сессионные данные непосредственно на форме, вместо этого используется стандартный механизм работы cookies между клиентом и сервером. В cookies и хранятся все пользовательские данные.

При выборе этого подхода опять же главной остается проблема безопасности наших данных, которые мы передаем на сервер – их легко подменить или украсть, они лежат в открытом виде. Также, если в настройках приватности браузера клиента отключен прием куки с сайтов, то такой вариант ведения сессии вовсе не будет работать.

Серверный механизм управления сессией (Session, SessionState)

Разберем, как работает механизм сессии со стороны сервера и со стороны клиента.

При стандартных настройках работы состояния сеанса для отслеживания серии запросов от одного клиента используется т.н. сессионная куки (session cookie). Алгоритм следующий:

  1. Абсолютно для каждого нового запроса на сервер (неважно, разные это клиенты или один) ASP.NET генерирует уникальный идентификатор сессии.
    Идентификатор сессии представляет собой случайно сгенерированное число, закодированное с помощью специального алгоритма в строку длиной 24 символа. Строка состоит из литералов от A до Z в нижнем регистре, а также чисел от 0 до 5. Пример идентификатора — hjnyuijl1pam3vox2h5i41in
  2. Если в течение текущего запроса данные клиента НЕ сохраняются для дальнейшей работы с ним, то и время жизни сессии этого клиента заканчивается (фактически не начавшись). При этом ранее сгенерированный идентификатор сессии становится недействительным (так как не был использован). В ответ на такой запрос клиент не получает ничего, чтобы связало его с новой сессией.
  3. Если же данные клиента (например, имя, адрес доставки товара) сохраняются на сервере, ASP.NET связывает сохраненные данные с ранее сгенерированным идентификатором сессии. Далее создается специальная сессионная куки, и в нее записывается также этот идентификатор. Эта куки добавляется в ответ на запрос и сохраняется в браузере клиента. Таким образом, создается связь клиента и его персонализированной информации на сервере. Новая сессия для данного клиента создана.
  4. При каждом следующем запросе клиент передает на сервер персональный идентификатор сессии через куки. Сервер сопоставляет идентификаторы и «узнает» клиента в рамках текущей сессии.
  5. До тех пор пока клиент передает свой персональный ключ, сессия считается активной. Сессия может закончиться по разным причинам, например, вручную на стороне сервера или по истечении какого-то установленного времени (таймаут).

От теории перейдем к практике. Давайте запрограммируем данный алгоритм и посмотрим, как он выполняется. Для этого используем специальный класс HttpSessionState . При работе в контроллере можно воспользоваться свойством HttpContext.Session . Работать с сессией очень просто, как с любой NameValueCollection :

В этом участке кода мы записываем в состояние сеанса имя пользователя. Это имя мы забираем с html-формы, которую он нам отправил. Дополнительно через свойства мы узнаем, создана ли эта сессия только что, то есть в рамках текущего запроса (если да, то и значение свойства IsNewSession будет равняться true), и уникальный идентификатор сессии. Этот идентификатор после обработки запроса будет автоматически записан в сессионную куки (если еще нет) и отправлен в ответе клиенту.

В браузере клиента можно наблюдать соответствующую куки и идентификатор его сессии:

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

Как видно, работать с сессиями очень просто и удобно. Большинство процессов, связанных с обработкой сессии, происходит автоматически в фоновом режиме. Естественно, разработчик может вмешаться на любой стадии обработки сессии и внести свои коррективы.

Давайте посмотрим на наиболее интересные свойства и методы класса HttpSessionState , которые чаще всего используются в работе:

Item[index] – возвращает элемент данных по его индексу
Item[key] – возвращает элемент данных по его ключу
Remove(index) – удаляет элемент данных по его индексу
Remove(key) – удаляет элемент данных по его ключу
Clear() – удаляет все данные
Count – возвращает общее количество элементов данных для текущей сессии
Abandon() – принудительно завершить сессию
SessionID — возвращает идентификатор текущей сессии
IsNewSession – возвращает true если сессия была создана в рамках текущего запроса
Timeout – возвращает число минут, допустимое между запросами, перед тем как сессия завершится по причине таймаута (по умолчанию, 20 минут)

Изменить настройки для сессии можно либо программно в коде посредством членов класса HttpSessionState , либо через конфигурацию приложения (файл web.config). Например:

В конфигурации выше мы указали, что таймаут сессии будет 40 минут, сессионные данные пользователя будут храниться в оперативной памяти, будут использоваться сессионные куки, также поменяли стандартное название такой куки на собственное.

Изучение сессии в ASP.Net

Written on 04 Сентября 2013 . Posted in ASP.NET

ОГЛАВЛЕНИЕ

Данная статья описывает сессию в ASP.Net 2.0. Разные типы сессии, ее конфигурация. Также описана сессия в веб-ферме, балансировщике нагрузки, веб-саде, и т.д.

Введение

Данная статья дает хорошее понимание сессии. В ней описаны основы сессии, разные типы хранения объекта сессии, поведение сессии в веб-ферме, сессия в балансировщике нагрузки и т.д. Также объяснены особенности поведения сессии в условиях реального производства.

Что такое сессия?

Интернет не сохраняет состояние, а значит, новый экземпляр класса веб-страницы вновь создается при каждой отправке страницы на сервер. Как известно, HTTP — протокол без сохранения состояния, он не способен хранить клиентскую информацию о странице. Если пользователь вставит какие-то данные и перейдет на следующую страницу, то эти данные потеряются, и пользователь не сможет извлечь данные. Что нужно? Нужно хранить информацию. Сессия позволяет хранить информацию в памяти сервера. Она поддерживает хранение любого типа объекта наряду с пользовательским объектом. Для каждого клиента данные сессии хранятся отдельно, то есть данные сессии хранятся согласно клиенту. Посмотрите на следующую схему.

Рис. Для каждого клиента данные сессии хранятся отдельно

Управление состоянием с помощью сессии – одно из лучших средств asp.net, потому что оно безопасно, прозрачно от пользователей, и в ней можно хранить любой объект. Наряду с плюсами, порой сессия вызывает проблему быстродействия для сайтов с интенсивным трафиком, потому что сессия хранится в памяти сервера, и клиенты читают данные из самого сервера. Рассмотрим плюсы и минусы использования сессии в веб-приложении.

Плюсы и минусы сессии

Ниже приводятся основные плюсы и минусы использования сессии. Все типы сессий подробно описаны далее.

Плюсы:
• Сессия помогает хранить состояния и данные пользователя во всем приложении.
• Она легко реализуется и может хранить любой объект.
• Хранит данные каждого клиента отдельно.
• Сессия безопасна и прозрачна для пользователя.

Минусы:
• Издержки быстродействия в случае большого числа пользователей, так как данные сессии хранятся в памяти сервера.
• Издержки, связанные с сериализацией и десериализацией данных сессии, так как в случае режимов сессии StateServer и SQLServer объект надо сериализовать перед сохранением.

Кроме того, есть много плюсов и минусов сессии, обусловленных типами сессии. Все они разобраны далее.

Сохранение и извлечение значений из сессии

Сохранение и извлечение значений сессии очень похоже на ViewState. С состоянием сессии можно взаимодействовать с помощью класса System.Web.SessionState.HttpSessionState, потому что он предоставляет встроенный объект сессии со страницами Asp.Net.

Следующий код применяется для сохранения значения в сессии

Значения извлекаются из сессии так:

можно сохранить другой объект в сессии. Следующий пример показывает, как сохранить DataSet в сессии.

а следующий код показывает извлечение dataset из сессии

Идентификатор сессии

Asp.Net использует 120- битный идентификатор для отслеживания каждой сессии. Он достаточно безопасен и не подлежит расшифровке. Когда клиент общается с сервером, между ними передается только идентификатор сессии. Когда клиент запрашивает данные, ASP.NET смотрит на идентификатор сессии и извлекает соответствующие данные.

Это делается путем следующих шагов:
• Клиент обращается к веб-сайту, и какая-то информация сохраняется в сессии.
• Сервер создает уникальный идентификатор сессии для этого клиента и сохраняет его в поставщике состояния сессии.
• Снова клиент запрашивает какие-то данные с этим уникальным идентификатором сессии у сервера.
• Сервер смотрит на поставщики сессии и извлекает сериализованные данные из сервера состояний и приводит тип объекта.

Посмотрите на наглядную схему,

Рис. Взаимодействие клиента, веб-сервера и поставщика состояний


Режим сессии и поставщик состояний

В ASP.NET есть следующие режимы сессии:

• InProc
• StateServer
• SQLServer
• Custom

Для каждого состояния сессии есть поставщик сессии. Следующая схема показывает, как они связаны.

Рис. Архитектура состояния сессии

Можно выбрать поставщик состояния сессии исходя из того, какое состояние сессии выбирается. Когда ASP.NET запрашивает любую информацию на базе идентификатора сессии, состояние сессии и его соответствующий поставщик отвечают за отправку надлежащей информации на базе пользователя. Следующая таблица показывает режим сессии вместе с именем ее поставщика.

Режим состояния сессии

Поставщик состояния

Объект в памяти

Есть еще один режим «Off». Если выбрать этот вариант, сессия будет отключена для приложения. Но использование сессии является целью, поэтому рассматриваются 4 режима состояния сессии.

Состояния сессии

Состояние сессии означает все настройки, сделанные для веб-приложения для сохранения сессии. Состояние сессии сообщает все о конфигурации сессии в web.config или из выделенного кода. В web.config, элементы используются для установки конфигурации сессии. Некоторые из них — Mode, Timeout, StateConnectionString, Custom provider и др. Рассмотрены все до единой части строки подключения. Перед рассмотрением режима сессии кратко ознакомимся с событием сессии.

Событие сессии

В Asp.net есть два типа событий сессии:

оба этих события обрабатываются в файле global.asax веб-приложения. При запуске новой сессии возбуждается событие session_start, а при закрытии или окончании сессии возбуждается событие Session_End.

Режим сессии

Уже обсуждался режим сессии в ASP.NET. Ниже приводятся разные типы режимов сессии, имеющиеся в ASP.Net.
• Off
• InProc
• StateServer
• SQLServer
• Custom

Если установить режим сессии=»off» в web.config, сессия будет отключена во всем приложении. Для этого надо сконфигурировать web.config таким образом:

Внутрипроцессный режим сессии

Это режим сессии по умолчанию в Asp.Net. Он хранит данные сессии в текущем домене приложения. Это лучший режим сессии исходя из быстродействия веб-приложения. Но главный недостаток в том, что данные теряются при перезапуске сервера. Есть еще несколько плюсов и минусов внутрипроцессного режима сессии. Они рассмотрены далее.

Обзор внутрипроцессного режима сессии

Внутрипроцессный режим хранит данные сессии в текущем домене приложения. Поэтому они легко и быстро доступны.

Внутрипроцессный режим сессии хранит данные сессии в объекте памяти в домене данного приложения. Этим управляет рабочий процесс в пуле приложений. Поэтому при перезапуске сервера данные сессии теряются. Если клиент запрашивает данные, поставщик состояния считывает данные из объекта в памяти и возвращает их клиенту. В web.config надо указать режим сессии и установить время ожидания.

Такая установка времени ожидания сессии сохраняет сессию в течение 30 минут. Это можно настроить и из выделенного кода.

В asp.net есть два типа событий сессии — Session_Start() и Session_End(). Это единственный режим, поддерживающий событие Session_End(). Это событие вызывается после истечения времени ожидания сессии. Общий порядок операций для внутрипроцессного состояния сессии таков:

От времени ожидания сессии зависит, когда вызовется Session_End(). Это очень быстрый механизм, потому что при сохранении и извлечении данных не происходит сериализации, и данные остаются в том же домене приложения.

Когда следует использовать внутрипроцессный режим сессии?

Внутрипроцессный – режим сессии по умолчанию. Он очень полезен для маленьких веб-сайтов и когда число пользователей очень маленькое. Избегайте внутрипроцессного режима в случае веб-сада (эта тема подробно рассмотрена далее).

Плюсы и минусы

Плюсы:
• Данные сессии хранятся в объекте памяти текущего домена приложения. Поэтому доступ к данным очень быстрый, и данные легко доступны.
• Для хранения данных при внутрипроцессном режиме сессии не требуется сериализация.
• Реализация очень простая, сходная с использованием состояния просмотра.

Минусы:
Несмотря на то, что внутрипроцессная сессия – самый быстрый, простой и стандартный механизм, он имеет много недостатков.
• Если рабочий процесс или домен приложения возвращается в исходное состояние, все данные сессии теряются.
• Хотя он самый быстрый, но много данных сессий и много пользователей снижают быстродействие из-за памяти.
• Его нельзя использовать в веб-саде.
• Этот режим сессии не подходит для веб-фермы.

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

Теперь рассмотрим другие доступные варианты для преодоления этой проблемы. Первым идет режим сервера состояний.

Режим сессии сервера состояний

Обзор режима сессии сервера состояний

Он также называется внепроцессным режимом сессии. Сервер состояний использует автономные службы Windows, не зависящие от IIS и способные работать на отдельном сервере. Этим состоянием сессии полностью управляет aspnet_state.exe. Этот сервер может работать в той же системе, но он находится вне основного домена приложения, где работает веб-приложение. При перезапуске процесса asp.net данные сессии сохраняются. Такой подход имеет несколько недостатков из-за издержек сериализации и десериализации, он также увеличивает издержки доступа к данным, так как при каждом извлечении данных сессии пользователем приложение обращается к другому процессу.

Конфигурация для режима сессии сервера состояний

В StateServer данные сессии хранятся в отдельном сервере, не зависящем от IIS и управляемом aspnet_state.exe. Этот процесс работает как службы windows. Эту службу можно запустить из консоли управления windows или из командной строки.

По умолчанию «тип запуска» службы состояний ASP.NET установлен на ручной, надо установить его как «автоматический» тип запуска

из командной строки, набрав «net start aspnet_state». По умолчанию эта служба слушает порт TCP 42424, но можно изменить порт из редактора реестра, как показывает рисунок ниже.

Теперь посмотрим на конфигурацию web.config для установки сервера состояний. Для установки сервера состояний надо задать stateConnectionString. Она будет идентифицировать систему, являющуюся работающим сервером состояний. По умолчанию stateConnectionString использует IP-адрес 127.0.0.1 (localhost) и порт 42424.

При использовании сервера состояний можно сконфигурировать атрибуты stateNetworkTimeOut, чтобы задать максимальное число секунд ожидания ответа от службы до отмены запроса. Время по умолчанию — 10 секунд.

При использовании сервера состояний объект должен сериализоваться при сохранении и десериализоваться при извлечении. Это описано в примере.

Как работает режим сессии сервера состояний?

Режим сессии сервера состояний используется для предотвращения ненужной потери данных сессии при перезапуске веб-сервера. Сервер состояний обслуживается процессом aspnet_state.exe как служба windows. Этот процесс хранит все данные сессии. Но надо сериализовать данные перед их сохранением в режиме сессии сервера состояний.

Как показано на рисунке выше, сначала клиент отправляет запрос веб-серверу, затем веб-сервер сохраняет данные сессии на сервере состояний. Сервер состояний может быть текущей системой или другой системой. Но он абсолютно независим от IIS. Адрес сервера состояний будет зависеть от установки атрибута stateConnectionString в web.config. если установить его в 127.0.0.1:42424, он будет хранить данные в самой локальной системе. Чтобы сменить адрес сервера состояний, надо сменить IP и убедиться, что aspnet_state.exe запущен и работает в той системе. Иначе выдается следующее исключение при попытке сохранить данные в сессии.

Любой объект должен быть сериализован перед сохранением в сессии. Эти данные сохраняются в системе сервера состояний с помощью поставщика состояний. При извлечении данных поставщик состояний возвращает данные. Полный порядок операций дан на рисунке ниже.

Пример режима сессии сервера состояний:

Это простой пример использования режима сессии сервера состояний. Пример веб-приложения был создан прямо на IIS, чтобы было легко понять его применение.

Шаг 1: Открыть Visual Studio > Файл(File)>Новый(New)> Веб-сайты(Web Sites). Выбрать расположение как HTTP и создать веб-приложение.

Теперь если вы откроете IIS, то увидите виртуальный каталог, созданный с именем вашего веб-приложения, в данном примере это StateServer.

Шаг 2: Создать простой пользовательский интерфейс, принимающий номер списка и имя ученика. Имя и список будут сохраняться в сессии сервера состояний. Также был создан класс «StudentInfo», приведенный ниже.

Теперь ознакомимся с кодом, отделенным от кода. Были добавлены две кнопки – одна для сохранения сессии, а вторая для извлечения сессии.

Шаг 3: Сконфигурировать web.config для сервера состояний, как уже было сказано. Убедиться, что aspnet_state.exe запущен и работает на сконфигурированном сервере.

Шаг 4: Запустить приложение

Ввести данные, нажать на Отправить. Следующий тест покажет, в чем именно польза сервера состояний.

Первый: Удалите ключевое слово [Serializable] из класса studentinfo и попробуйте запустить приложение. При нажатии на кнопку «Отправить» вы получите следующую ошибку

которая ясно говорит, что надо сериализовать объект перед сохранением.

Второй: Запустите приложение, сохраните данные, нажав на кнопку «Отправить». Перезапустите IIS

Теперь в случае InProc вы уже потеряли данные сессии, но это StateServer. Щелкните по «Восстановить сессию» и получите исходные данные, потому что данные сервера состояний не зависят от IIS. Сервер состояний хранит данные отдельно.

Третий: Остановите aspnet_state.exe из консоли управления службами Windows и отправьте данные. Вы получите следующую ошибку,

потому что процесс сервера состояний не работает. Не забывайте про три перечисленных момента.

Плюсы и минусы

Исходя из вышесказанного:

Плюсы
• Данные хранятся отдельно от IIS, поэтому проблемы с IIS не мешают данным сессии.
• Он полезен в веб-ферме и веб-саде.

Минусы
• Процесс медленный из-за сериализации и десериализации
• Сервер состояний всегда должен быть запущен и работать.

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

Режим сессии SQL Server

Обзор режима сессии SQL Server

Этот режим сессии обеспечивает более безопасное и надежное управление сессиями в asp.net. В этом режиме сессии данные сессии сериализуются и сохраняются в базе данных SQL Server. Основные недостатки данных методов хранения сессии – издержки, связанные с сериализацией и десериализацией данных. Это лучший вариант для применения в веб-фермах.

Для настройки SQL Server надо воспользоваться двумя скриптами sql.

• Для установки: InstallSqlState.sql
• Для удаления: UninstallSQLState.sql

Простейший способ сконфигурировать SQL Server – использовать команду aspnet_regsql. Использование этого файла подробно объяснено в разделе конфигурации. Это наиболее полезное управление состоянием в веб-ферме.

Когда следует использовать режим сессии SQL Server?


• Режим сессии SQL Server – более надежное и безопасное управление состоянием сессии.
• Он хранит данные в централизованном месте (база данных).
• Следует использовать режим сессии SQL server, когда нужна более безопасная реализация сессии.
• Если сервер часто перезапускается, можно реализовать SQL server.
• Этот режим прекрасно подходит для веб-фермы и веб-сада (подробно объяснено далее).
• Можно использовать режим сессии SQL server, когда сессия совместно используется двумя разными приложениями.

Конфигурация для режима сессии SQL Server

В режиме сессии SQL Server данные сессии сохраняются в SQL Server, поэтому сначала надо прописать строку подключения к базе данных в web.config.Атрибут sqlConnectionString используется для указания строки подключения в web.config.

После установки строки подключения надо сконфигурировать SQL Server. SQL server конфигурируется с помощью команды aspnet_regsql следующим образом:

Шаг 1: Из командной строки перейдите в ваш каталог версии среды разработки

Шаг 2: Выполните команду aspnet_regsql со следующими параметрами

Ознакомьтесь с параметрами и их назначениями

Параметры

Описание

Добавить поддержку режима состояния сессии SQLServer .

P означает сохраненный. Он сохраняет данные сессии на сервере.

Задать имя сервера

Задать имя пользователя

После выполнения вы получите следующее сообщение,

Шаг 3: Откройте SQL Server Management Studio. Убедитесь, что новая база данных ASPState была создана, и в ней есть две таблицы,
• ASPStateTempApplications
• ASPStateTempSessions

Теперь измените строку конфигурации примера сервера состояний и запустите то же самое приложение, что и для сервера состояний.
Сохраните список и имя пользователя и щелкните по кнопке «Отправить», и откройте таблицу ASPStateTempSessions из SQL Server Management Studio, и увидите ваши данные сессии,

Теперь проделайте следующий тест, уже описанный в режиме сервера состояний.
1. Удалите ключевое слово serialize из класса StydentInfo
2. Перезапустите IIS и щелкните по «Восстановить сессию»
3. Остановите службу SQL Server

Плюсы и минусы

Плюсы:
• Данные сессии не страдают при перезапуске IIS.
• Самое надежное и безопасное управление сессиями.
• Данные хранятся в централизованном месте, легко доступном из другого приложения.
• Очень полезен для веб-фермы и веб-сада.

Минусы:
• Обработка очень медленная по характеру.
• Сериализация и десериализация объекта создает издержки для приложения.
• Поскольку данные сессии обрабатываются в другом сервере, приходится следить за SQL server. Он всегда должен быть запущен и работать.

Пользовательский режим сессии

Обзор пользовательского режима сессии:

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

Можно реализовать пользовательские поставщики, сохраняющие данные сессии в других механизмах хранения путем наследования от класса SessionStateStoreProviderBase. Можно генерировать новый идентификатор сессии путем реализации ISessionIDManager.

Следующие методы вызываются во время реализации пользовательской сессии:

В методе Initialize устанавливается пользовательский поставщик. Он будет инициализировать соединение с заданным поставщиком. SetItemExpireCallback используется для установки SessionTimeOut, можно зарегистрировать любые методы, которые вызовутся при окончании сессии. InitializeRequest вызывается при каждом запросе, а CreateNewStoreData используется для создания нового экземпляра SessionStateStoreData.

Когда следует использовать пользовательский режим сессии?

Пользовательский режим сессии можно использовать в следующих случаях:
• Надо хранить данные сессии не в SQL Server.
• Надо использовать существующую таблицу для хранения данных сессии.
• Надо создать собственный идентификатор сессии.

Какая конфигурация требуется для него?

Надо сконфигурировать web.config так,

Плюсы и минусы

Плюсы:
• Можно использовать существующую таблицу для хранения данных сессии. Это полезно, когда приходится использовать старую базу данных вместо SQL Server.
• Он не зависит от IIS, поэтому перезапуск веб-сервера никак не влияет на данные сессии.
• Можно создать собственный алгоритм генерации идентификатора сессии.

Минусы:
• Обработка данных очень медленная.
• Создание пользовательского поставщика состояния – низкоуровневая задача, требующая аккуратного подхода для обеспечения безопасности.

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

Обзор производственного развертывания

Производственная среда означает, что приложение развертывается на настоящем рабочем сервере. Развертывание приложения на настоящем сервере – большая трудность для веб-разработчика, потому что в масштабной производственной среде много пользователей, и невозможно справиться с нагрузкой от них с помощью одного сервера. Отсюда появились модели веб-фермы, балансировщика нагрузки, веб-сада, и т.д.
Недавно одно веб-приложение было развернуто в реальной производственной среде, доступной для миллиона пользователей, где было более 10 Active Directory, более 10 веб-серверов на балансировщике нагрузки и много серверов баз данных, серверов Exchange Server, серверов LCS и др. Было несколько веб-серверов. Основной риск, связанный с несколькими серверами, — управление сессиями. Следующий рисунок показывает общую схему производственной среды.

Далее описаны разные ситуации, которые надо учесть при развертывании приложения.

Пул приложений

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

Удостоверение пула приложений

Конфигурация удостоверения пула приложений – важный аспект безопасности в IIS 6.0 и IIS 7.0, так как она определяет удостоверение рабочего процесса, когда процесс обращается к ресурсу. Эти настройки исходят из IIS 6.0. В IIS 7.0 есть заранее заданные удостоверения, такие же, как и в IIS 6.0.

Удостоверение пула приложений

Описание

LocalSystem – встроенная учетная запись, имеющая права администратора на сервере. Она может обращаться к локальным и удаленным ресурсам. Для любого вида доступа к файлам или ресурсам сервера надо задать удостоверение пула приложений Локальная система.

LocalServices – встроенная учетная запись имеет права аутентифицированной учетной записи локального пользователя. Ей запрещен доступ к сети.

Удостоверение пула приложений по умолчанию. NetworkServices имеет права аутентифицированной учетной записи локального пользователя.

Создание и назначение пула приложений

Откройте консоль IIS, щелкните правой кнопкой мыши по «Папка пула приложений» (Application Pool Folder) > Создать новый (Create New)

Введите Идентификатор пула приложений и нажмите Ok.

Теперь щелкните правой кнопкой мыши по «Виртуальный каталог» (используется StateServer Web sites) и назначьте StateServerAppPool виртуальному каталогу сервера состояний.

Итак, StateServer Web sites будет работать независимо в StateServerAppPool. Любая проблема, связанная с другим приложением, не повлияет на ваше приложение. Это главное преимущество создания отдельного пула приложений.

Веб-сад

По умолчанию каждый пул приложений работает с одним рабочим процессом (W3Wp.exe). Можно назначить несколько рабочих процессов одному пулу приложений. Пул приложений с несколькими рабочими процессами называется веб-сад. Много рабочих процессов в одном и том же пуле приложений иногда дают лучшую производительность и время реакции приложения. Каждый рабочий процесс должен иметь свой собственный поток и область памяти.

Как показано на рисунке, в сервере IIS может быть несколько пулов приложений, и каждый пул приложений имеет минимум один рабочий процесс. Веб-сад должен содержать несколько рабочих процессов.

Есть определенные ограничения на использование веб-сада в веб-приложении. Если используется внутрипроцессный режим сессии, приложение не будет работать правильно, потому что сессия будет обрабатываться другим рабочим процессом. Во избежание данной проблемы надо использовать внепроцессный режим сессии. Можно использовать «Сервер состояния сессии» или «Состояние сессии SQL-Server».

Главное преимущество: Рабочие процессы в веб-саде разделяют запросы, поступающие в конкретный пул приложений. Если один рабочий процесс откажет, другой рабочий процесс сможет продолжить обработку запросов.

Как создать веб-сад?

Щелкните правой кнопкой мыши по Пул приложений > Перейти во вкладку Производительность > Выбрать секцию веб-сад (выделена на рисунке)

По умолчанию стоит 1, измените на несколько.

Как сессия зависит от веб-сада?

InProc управляется рабочим процессом. Он хранит данные внутри своего объекта памяти. Если есть несколько рабочих процессов, то обрабатывать сессию будет очень трудно, потому что каждый рабочий процесс имеет свою собственную память. Поэтому если первый запрос пользователя уходит к WP1, и он хранит его данные сессии, и второй запрос того же пользователя уходит к WP2, и пользователь пытается извлечь данные сессии, они не вернутся, и выбросится ошибка. Поэтому не используйте веб-сад во внутрипроцессном режиме сессии.

В случае веб-сада можно использовать режим сессии StateServer или SQLServer, потому что эти два режима сессии не зависят от рабочего процесса. В примере показано, что после перезапуска IIS данные сессии успешно извлекаются.

Кэш данных и объект сеанса в ASP.Net

Должны ли храниться динамические бизнес-объекты для сайта в сеансе пользователей или использовать кэширование ASP.Net(такие объекты, как заказы, информация профиля и т.д.)?

Я работал с сайтами, которые использовали сеансы для хранения бизнес-объектов, но мне было интересно. Каковы преимущества или недостатки кеширования?

Если объекты разделяются между сеансами пользователя, используйте кеш. Если объекты уникальны для каждого сеанса, возможно, потому, что они управляются разрешениями, а затем сохраняйте их в сеансе. Сам процесс in-process хранится в кеше, поэтому решающим фактором действительно должна быть область данных.

Кэширование — это просто кеширование. Вы никогда не можете опираться на записи, поэтому нет никаких предположений в этом отношении: будьте готовы перейти непосредственно к БД (или где-либо еще), чтобы восстановить данные.

С другой стороны, сеанс больше подходит для хранения объектов, хотя лично я стараюсь избегать хранения сеанса в пользу БД. Обычно я делаю это, абстрагируя хранилище за непрозрачным интерфейсом ISessionStoreService:

а затем «соответствующая реализация зависимостей», будь то InmemorySessionStore, DbSessionStore или что-то еще.

Системный кэш ASP.NET является глобальным для приложения, где сеанс уникален для текущего пользователя. Если вы решили использовать глобальный кеш для хранения объектов, вам нужно будет создать стратегию идентификации объектов, чтобы вы могли получить правильные объекты для своих пользователей.

Если вы хотите повысить производительность, вам лучше было бы заменить состояние сеанса ASP.NET кешем распределенной памяти, таким как скорость Microsoft. Microsoft опубликовала статьи о том, как заменить использование сеанса на целевую скорость. Вы также можете использовать Memcache или другие аналогичные продукты соответствующим образом.

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

Session = > Веб-страница с пошаговым интерфейсом (например, онлайн-тест).
Cache = > Информация, отображаемая в виде своего рода виджета погоды (например, того, что у Google на странице igoogle.com).
Надеюсь, это поможет.

Хотя вы можете сохранить свой бизнес-объект в кеше, но Cache предназначен для повышения производительности, а не для управления штатами. Представьте, что у вас есть процесс получения 1000 записей из базы данных (и это занимает около 3 секунд), и вам понадобится это на несколько минут. Вы можете хранить свои объекты в кеше и устанавливать дату истечения срока действия, приоритет и зависимость от него (например, SqlDependency или FileDependency), поэтому для следующих запросов вы можете использовать данные Cached вместо их извлечения из базы данных. Вы можете сохранить свой объект в сеансе, но вы не можете установить зависимость для сеанса по умолчанию. Также у Cache есть уникальное поведение, которое, когда система нуждается в памяти, будет освобождать объекты из кеша в зависимости от его приоритета. Объекты кэша являются глобальными для Приложения и распределяются между всеми пользователями, но сеанс не используется совместно и используется для каждого пользователя (сеанса).


Управление состоянием приложения¶

В ASP.NET Core статусом приложения можно управлять разными способами. В этой статье мы рассмотрим некоторые варианты, а также установим и настроим поддержку состояния сессий в приложениях ASP.NET Core.

Опции Application State¶

Application state (состояние приложения) касается всех данных, которые используются для представления текущего состояния приложения. Это касается и глобальных, и конкретных данных. В предыдущих версиях ASP.NET (и даже ASP) имелась встроенная поддержка глобальных хранилищ состояний Application и Session , а также некоторые другие опции.

У хранилища Application были почти такие же характеристики, что и у ASP.NET Cache . В ASP.NET Core Application больше не существует; приложения, написанные для предыдущих версий ASP.NET и перемещенные в ASP.NET Core заменяют Application реализацией Caching .

Разработчики приложений вольны использовать различные провайдеры состояний приложений в зависимости от разных факторов:

  • Как долго должны существовать данные?
  • Какова величина данных?
  • Каков формат этих данных?
  • Можно ли их сериализовать?
  • Насколько чувствительны данные? Могут ли они храниться на стороне клиента?

В зависимости от ответов на эти вопросы состояние приложения ASP.NET Core может управляться разными способами.

HttpContext.Items¶

Коллекция Items — это лучшее место для хранения данных, которые нужны для обработки определенного запроса. Их содержание сбрасывается после каждого запроса. Это что-то вроде связки между компонентами и middleware, которые работают на разных этапах запроса и не имеют прямого отношения к данным, передающим параметры и возвращаемые значения. См. Работа с HttpContext.Items.

Строка запроса и Post¶

Состояние запроса может быть передано другому запросу, если вы добавите значение строке нового запроса или используете POST. Такие технологии не нужно использовать с чувствительными данными, поскольку здесь данные отправляются клиенту, а затем обратно серверу. Лучше всего использовать такой способ с небольшим количеством данных. Строки запросов особенно полезны для определения состояния постоянным образом, и таким образом создаются ссылки, сохраняющие состояние, а затем они отправляются через имейлы или социальные сети для возможного дальнейшего использования. Поскольку URL со строками запросов можно легко делиться, вы должны позаботиться об избежании CSRF-атак) (например, даже если предположить, что только зарегистрированные пользователи могут выполнять некоторые действия с помощью таких URL, атакующий может попробовать использовать такой URL как зарегистрированный пользователь).

Некоторое количество данных, связанных с состоянием, может быть сохранено в куки. Они отправляются с каждым запросом, так что их размер должен быть минимальным. В идеале, нужно использовать только идентификатор с актуальными данными, сохраненными на сервере, которые связаны с идентификатором.

Сессия¶

Сессионное хранилище использует куки-идентификатор, чтобы получить доступ к данным, связанным с определенной сессией браузера (серией запросов от определенного браузера). Вы не должны думать, что сессия ограничена одним пользователем, так что аккуратно храните информацию в разделе Session. Это хорошее место для хранения состояния приложения, которое касается определенной сессии, но которое не нужно отслеживать постоянно (или которое можно восстановить из хранилища состояний). См. Установка и настройка сессий.

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

Конфигурация¶

Конфигурация может считаться некоторой формой хранилища данных приложения, хотя обычно во время запуска приложения она является read-only. См. Конфигурация .

Другие постоянные хранилища¶

Другие постоянные хранилища, например, Entity Framework и база данных или Azure Table Storage также могут служить для сохранения состояния приложения, но ASP.NET напрямую их не поддерживает.

Работа с HttpContext.Items¶

HttpContext поддерживает коллекцию типа IDictionary object> , которая называется Items . Эта коллекция доступна при запуске HttpRequest` и сбрасывается в конце каждого запроса. Вы можете получить к ней доступ при помощи запроса или присвоения значения ключу.

Например, Связующее ПО (Middleware) может что-то добавить в коллекцию Items :

и далее в потоке другой кусок связующего ПО может добраться до этого:

Ключи в Items являются простыми строками, и если вы разрабатываете связующее ПО, которое должно работать с несколькими приложениями, вам стоит добавить ключам уникальный идентификатор, чтобы избежать проблем с ключами (например, “MyComponent.isVerified” вместо “isVerified”).

Установка и настройка сессий¶

В ASP.NET Core есть пакет, который предоставляет связующее ПО для управления состоянием приложения. Вы можете установить его, добавив ссылку на пакет в файл project.json.

После установки пакета нужно настроить Session в классе Startup . Session создается вверху IDistributedCache , так что вам нужно настроить все это, иначе вы получите ошибку.

Если вы не настроите хотя бы одну реализацию IDistributedCache , у вас появится исключение “Unable to resolve service for type ‘Microsoft.Extensions.Caching.Distributed.IDistributedCache’ из-за попытки активировать ‘Microsoft.AspNet.Session.DistributedSessionStore’.”

ASP.NET поставляется с несколькими реализациями IDistributedCache , включая опцию in-memory (используется только во время разработки и тестирования). Чтобы настроить сессию при помощи этой опции, добавьте Microsoft.Extensions.Caching.Memory в пакет project.json, а следующее в ConfigureServices :

Затем добавьте следующее в Configure перед app.UseMVC() , и вы будете готовы использовать сессию:

После установки и настройки вы будете готовы использовать Session из HttpContext .

Если вы попытаетесь использовать Session перед вызовом UseSession , у вас появится исключение InvalidOperationException , что будет написано следующее: “Session has not been configured for this application or request.”

Если вы попытаетесь создать новую Session (пока не было создано куки сессии) после того, как вы начали создавать поток Response , у вас также появится исключение InvalidOperationException , где будет говорится, что “The session cannot be established after the response has started”. Это исключение, возможно, не будет отображено в браузере; вам потребуется просмотреть серверный лог, чтобы найти его:

Детали реализации¶

Сессия использует куки, чтобы отслеживать и устранять неоднозначные моменты между запросами с разных браузеров. По умолчанию этот куки называется ”.AspNet.Session”. Далее, по умолчанию этот куки не указывает домен, и он недоступен для скриптов на клиентской стороне (поскольку CookieHttpOnly установлен на true ).

IdleTimeout (используется на сервере независимо от куки) можно переписать при настройке Session при помощи SessionOptions :

IdleTimeout используется сервером для определения того, когда сбрасывается сессия. Каждый запрос передается связующему ПО Session (независимо от того, считывается или записывается Session внутри данного ПО), и это сбрасывает таймаут. Обратите внимание, что все это происходит независимо от сброса куки.

Если два запроса пытаются изменить контекст сессии, сделает это последний. Кроме того, все виды контекста сессии сохраняются совместно. Это обозначает, что если два запроса меняют различные части сессии (разные ключи), они будут все равно влиять друг на друга.

ISession¶

После установки и настройки сессии вы ссылаетесь на нее через HttpContext, который предоставляет свойство Session типа ISession. Вы можете использовать этот интерфейс, чтобы получать и устанавливать значения в Session , в качестве byte[] .

Поскольку Session создается вверху IDistributedCache , вы всегда должны сериализовать сохраняемые экземпляры объекта. Интерфейс работает с byte[] , а не просто с object . Однако существуют методы расширения, которые упрощают работу с простыми типами, такими как String и Int32 , а также упрощают получение значений byte[] из сессии.

Если вы сохраняете более сложные объекты, вам нужно сериализовать объект в byte[] , чтобы его сохранить, а при получении десериализовать его.

Рабочий пример использования сессии¶

В данном примере показано, как работать с Session, включая сохранение и получение простых типов, а также пользовательских объектов. Если вы хотите узнать, что происходит после истечения сессии, то вы увидите это на данном примере, поскольку сессия длится всего 10 секунд:

Когда вы впервые переходите на веб сервер, тут представлен скриншот, показывающий, что сессия еще не была установлена:

Такое поведение по умолчанию происходит из-за связующего ПО в Startup.cs , который запускается тогда, когда делается запрос, у которого нет установленной сессии (обратите внимание на выделенные сессии):

GetOrCreateEntries — это вспомогательный метод, который получает экземпляр RequestEntryCollection из Session , если сессия существует; в ином случае он создает коллекцию и возвращает ее. Коллекция содержит экземпляры RequestEntry , в которых находятся различные запросы, которые сделал пользователь во время текущей сессии.

Типы, которые хранятся в сессии, помечаются [Serializable] .

Извлечение текущего экземпляра RequestEntryCollection происходит при помощи вспомогательного метода GetOrCreateEntries :

Если в Session существует объект, он извлекается как тип byte[] , а затем десериализуется с помощью MemoryStream и BinaryFormatter . Если объект не находится в Session , метод извлекает новый экземпляр RequestEntryCollection .

В браузере нажатие гиперссылки “Establish session” направляет запрос по пути “/session” и возвращает такой результат:

Обновление страницы включает счетчик; возврат к корню сайта (после нескольких запросов) имеет вот такой итог, то есть, здесь подсчитаны все запросы, которые были сделаны во время этой сессии:

Работа с сессиями происходит с помощью связующего ПО, которое направляет запросы на “/session”:

Запросы по этому пути получат или создадут RequestEntryCollection , добавят к ней текущий путь, а затем сохранят сессию с помощью вспомогательного метода SaveEntries :

SaveEntries показывает, как превратить пользовательский объект в byte[] для сохранения в Session с помощью MemoryStream и BinaryFormatter .

Пример включает в себя некоторое связующее ПО, которое стоит упомянуть, и оно работает с путем “/untracked”. Вот его настройки:

Кэш данных против объекта сеанса в ASP.Net

Если динамический бизнес-объекты для сайта будет храниться в сессии пользователей или использовать кэширование ASP.Net (объекты, такие как заказы, профили и т.д.)?

Я работал с сайтами, которые используются для хранения сессий бизнес-объектов, но мне было интересно . Каковы преимущества и недостатки кэширования?

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

Кэширование — это всего лишь кэширование. Вы никогда не можете полагаться на записи, находящихся там, так что никаких предположений не должно быть сделано в этом отношении: будьте готовы идти прямо к БД (или где-либо еще), чтобы refetch данные.

Сессия, с другой стороны, больше подходит по отношению к хранению предметов, хотя лично я стараюсь избегать сессионный магазина в пользу БД. Я обычно делаю что абстрагируясь от магазина за непрозрачной ISessionStoreService интерфейс:

а затем «зависимость инъекционные» надлежащего осуществления, будь то InmemorySessionStore , DbSessionStore или любой другой .

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

Сессия => Веб — страница с пошаговым интерфейсом (онлайн тест, например).
Кэш => Информационный отображается в какой — то виджет погоды (как тот , что Google имеет в своей странице igoogle.com).
Надеюсь это поможет.

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

Если вы хотите, чтобы повысить производительность, было бы лучше заменить состояние сеанса ASP.NET с распределенной кэш-памяти, такие как скорость Microsoft. Microsoft опубликовал статьи о том, чтобы заменить использование сеанса для скорости цели. Вы можете также использовать Memcache или другие подобные продукты в соответствующей форме.

Несмотря на то, что вы можете хранить свой бизнес-объект в кэше, но кэш предназначен для повышения производительности не государственное управление. Представьте, что у вас есть процесс получения 1000 записей из базы данных (и это займет около 3 секунд), и вы будете нуждаться в этом в течение нескольких минут. Вы можете хранить объекты в кэше и установить дату истечения срока, приоритет и зависимость к нему (как SqlDependency или FileDependency), так и для последующих запросов можно использовать кэшированные данные вместо retriving его из базы данных. Вы можете сохранить свой объект в сессии, но вы не можете установить зависимость для сессии по умолчанию. Также Cache имеет уникальное поведение, когда система нуждается в памяти он будет выпускать объекты из кэша в зависимости от его приоритета. объекты Cache являются глобальными для применения и распределяются между всеми пользователями, но сессия не является общим, и это полезная для каждого пользователя (Session).

Страница «ASP»

Страница свойств ASP предназначена для управления списком параметров конфигурации (классического) ASP.

Список Отобразить позволяет выбрать один из следующих вариантов, которые определяют способ представления параметров: Понятные имена, Имена параметров конфигурации или Оба имени.

Список элементов пользовательского интерфейса


В приведенной ниже таблице содержатся описания элементов интерфейса, которые доступны на странице компонента и на панели Действия.

Элементы страницы компонента

Кодовая страница [codePage]

Указывает для приложения ASP кодовую страницу по умолчанию.

Включить буферизацию [bufferingOn]

Указывает, следует ли в приложении ASP буферизовать вывод. Значение по умолчанию – True.

Разрешить поблочное шифрование [enableChunkedEncoding]

Указывает, включено ли в службе веб-публикаций шифрование данных частями (HTTP 1.1). Значение по умолчанию – True.

Разрешить выдачу резервного HTML [enableAspHtmlFallback]

Управляет поведением ASP при переполнении очереди запросов. Если установлено значение True, то в указанном случае ASP произведет поиск HTML-файла, к имени которого добавлен суффикс «_asp», и если такой файл будет найден, возвратит его. Например, если обрабатывается запрос к файлу «Hello.asp», то возвращаемый HTM-файл должен иметь имя «Hello_asp.htm». Если такой файл не существует, клиенту будет возвращена HTTP-ошибка 500.13 (Сервер перегружен). Если установлено значение False, то также будет возвращена ошибка. Значение атрибута по умолчанию – True.

Включить пути к родительским каталогам [enableParentPaths]

Указывает, допускает ли страница ASP указание пути относительно текущего каталога (при использовании записи «. \») или выше текущего каталога. Значение по умолчанию – False.

Интервал проверки подключения клиента [queueConnectionTestTime]

Указывает период времени, в течение которого должен быть обслужен запрос, поставленый в очередь. Если он находился в очереди дольше, чем указывает данный атрибут, то перед выполнением запроса ASP проверяет, подключен ли еще клиент к серверу. Если соединение с клиентом разорвано, то запрос не обрабатывается и удаляется из очереди. Значение по умолчанию – 3 секунды.

Максимальный размер основного текста запроса [maxRequestEntityAllowed]

Определяет максимальный размер в байтах основного текста запроса ASP. Значение по умолчанию – 200 000 байт.

Длина очереди [requestQueueMax]

Задает максимальное число запросов ASP, которые могут находиться в очереди. Значение по умолчанию – 3000.

Время ожидания очереди запросов [queueTimeout]

Определяет максимальный период времени, в течение которого запрос сценария ASP может ожидать в очереди. Значение по умолчанию – 00:00:00 (неограниченно).

Предел буферизации ответов [bufferingLimit]

Устанавливает максимальный размер буфера ASP. Если буферизация ответа включена, это свойство задает максимальный размер в байтах, который ASP-страница может записать в буфер ответа, до того как произойдет его очистка. Значение по умолчанию – 4 194 304 байт.

Время ожидания сценария [scriptTimeout]

Задает период времени по умолчанию, в течение которого страницам ASP разрешено выполнение сценария. По прошествии этого времени предпринимается попытка остановить сценарий и в журнал событий Windows записывается соответствующее событие. Значение по умолчанию – 1 мин 30 сек.

Максимальное число потоков на процессор [processorThreadMax]

Задает максимальное число рабочих потоков на процессор, которые службы IIS могут создать при обработке запросов ASP. Значение по умолчанию – 25.

Задает код языка (LCID) по умолчанию для приложения. LCID определяет способ форматирования даты, времени и денежных единиц. Код по умолчанию – 1033 (en-us), обозначающий английский язык (США).

Перезапуск при изменении конфигурации [enableApplicationRestart]

Определяет, следует ли автоматически перезапускать приложение ASP при изменении его критических параметров конфигурации. Значение по умолчанию – True.

Подсчет номеров строк [calcLineNumber]

Указывает, следует ли ASP подсчитывать и хранить номера каждой из строк выполняемого кода для их последующей выдачи в сообщениях об ошибках. Значение по умолчанию – True.

Перехватывать исключения компонентов COM [exceptionCatchEnable]

Определяет, должны ли страницы ASP перехватывать исключения, возникшие в компонентах. Если установлено значение False, то страницы ASP не перехватывают исключения, возникшие в компонентах. Это может привести к обработке исключения на другом уровне обработки, например сценарием VB Script или рабочим процессом IIS (обычно это приводит к завершению рабочего процесса). Значение по умолчанию – True.

Разрешить отладку на стороне клиента [appAllowClientDebug]

Указывает, включена ли отладка ASP на стороне клиента. Значение по умолчанию – False.

Разрешить запись в журнал ошибочных запросов [logErrorRequests]

Определяет, записывает ли веб-сервер ошибки ASP в раздел приложений журнала событий Windows. По умолчанию ошибки ASP выводятся в веб-браузер клиента и в файлы журнала IIS. Значение по умолчанию – True.

Разрешить отладку на стороне сервера [appAllowDebugging]

Указывает, включена ли отладка ASP на сервере. Значение по умолчанию – False.

Запись ошибок в журнал событий [errorsToNTLog]

Определяет, какие ошибки ASP записываются в журнал событий Windows. По умолчанию ошибки ASP выводятся в веб-браузер клиента и в файлы журнала IIS. Значение по умолчанию – False.

Выполнять функции On End анонимно [runOnEndAnonymously]

Определяет, будут ли глобальные функции ASP SessionOnEnd и ApplicationOnEnd запускаться от имени анонимного пользователя. Если значение атрибута False, эти функции не запускаются. Значение по умолчанию – True.

Сообщение об ошибке сценария [scriptErrorMessage]

Определяет сообщение об ошибке, передаваемое браузеру, если отладочные сведения об ошибке не отправляются клиенту. По умолчанию выдается следующее сообщение: «Ошибка на сервере при обработке URL-адреса. Обратитесь к системному администратору».

Выводить ошибки в веб-браузер [scriptErrorSentToBrowser]

Определяет, должен ли веб-сервер отправлять браузеру клиента отладочную информацию об ошибке (код и описание ошибки, имя файла и номер строки) помимо ее регистрации в журнале событий IIS. Значение по умолчанию – True.

Язык сценариев [scriptLanguage]

Задает используемый по умолчанию язык сценариев для всех приложений ASP на данном веб-сервере. Значение по умолчанию – «VBScript».

Путь к каталогу кэша [diskTemplateCacheDirectory]

Содержит имя каталога, в котором ASP сохраняет скомпилированные шаблоны ASP после переполнения кэша в памяти. Значение по умолчанию — systemroot\inetpub\temp\ASP Compiled Templates.

Включить кэширование библиотек типов [enableTypelibCache]

Указывает, производится ли кэширование на сервере библиотеки типов. Значение по умолчанию – True.

Максимальное число файлов, кэшируемых на диске [maxDiskTemplateCacheFiles]

Указывает максимальное число сохраняемых скомпилированных шаблонов ASP. Значение по умолчанию – 2 000.

Максимальное число файлов, кэшируемых в памяти [scriptFileCacheSize]

Определяет число помещаемых в кэш заранее скомпилированных файлов сценариев. Если атрибут имеет значение 0, то файлы сценариев не кэшируются. Значение 4 291 967 295 указывает, то кэшируются все запрошенные файлы сценариев. Это свойство предназначено для настройки производительности в зависимости от объема доступной памяти и интенсивности обмена данными. Значение по умолчанию – 500.

Максимальное число кэшируемых обработчиков сценариев [scriptEngineCacheMax]

Задает максимальное число обработчиков сценариев, кэшируемых в памяти ASP-страницами. Значение по умолчанию – 250.

Разрешить параллельный вызов компонентов [appServiceFlags]

Включает работу параллельных сборок COM+, что позволяет ASP-приложению указать, какую версию системной DLL-библиотеки или COM-компонента следует использовать. Значение по умолчанию – False.

Включить регистрацию событий COM+ [appServiceFlags]

Включает средство регистрации событий COM+, которое позволяет администраторам и разработчикам производить отладку приложений ASP. Значение по умолчанию – False.

Выполнять в MTA [executeInMta]

Определяет, следует ли ASP выполнять сценарии в многопоточном отделении. Значение по умолчанию – False.

Учитывать потоковую модель компонента [trackThreadingModel]

Указывает, должна ли в IIS выполняться проверка потоковой модели для всех компонентов, создаваемых приложением. Значение по умолчанию – False.

Код раздела [partitionID]

Этому свойству присваивается идентификатор GUID раздела COM+. Если оно определено, установите для элемента Использовать раздел значение True.

Параллельно используемый компонент [sxsName]

Этому свойству присваивается имя приложения COM+. Если оно определено, установите для элемента Разрешить параллельный вызов компонентов значение True.

Использовать раздел [appServiceFlags]

Изолирует каждое из приложений в своем разделе COM+. Если для этого свойства установлено значение True, необходимо определить значение для элемента Код раздела. Значение по умолчанию – False.

Разрешить сохранение состояния сеанса [allowSessionState]

Включает сохранение состояния сеанса для приложения ASP. Значение по умолчанию – True.

Максимальное число сеансов [max]

Задает максимально допустимое число параллельных сеансов в IIS. Значение по умолчанию – 2 147 483 647.

Создать идентификатор для безопасного подключения [keepSessionIdSecure]

Создает новый файл cookie при переходе от незащищенного к безопасному подключению. Значение по умолчанию – True.

Время ожидания [timeout]

Задает период времени, в течение которого будет поддерживаться объект Session после обработки последнего связанного с ним запроса. Значение по умолчанию – 20 минут.

Элементы панели «Действия»

Имя элемента Описание

Позволяет сохранить изменения, внесенные на странице компонента.

Позволяет отменить изменения, внесенные на странице компонента.

Илон Маск рекомендует:  Что такое код j2me
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Имя элемента Описание