Что такое код asp @enablesessionstate


Содержание

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

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

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

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

Архитектура сеанса

Управление сеансом не является частью HTTP-стандарта. Поэтому для отслеживания информации сеанса и ее привязки к соответствующему ответу ASP.NET приходится выполнять дополнительную работу.

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

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

При каждом новом запросе ASP.NET генерирует новый идентификатор сеанса до тех пор, пока состояние сеанса не будет фактически использовано для сохранения какой-то информации. Такое поведение позволяет немного увеличить производительность. Коротко это можно объяснить так: зачем тратить время на сохранение идентификатора сеанса, если он не используется?

Когда ASP.NET обрабатывает HTTP-запрос, тот проходит через конвейер различных модулей, которые могут реагировать на события приложения. Одним из модулей в этой цепочке является SessionStateModule (который находится в пространстве имен System.Web.SessionState). Этот модуль генерирует идентификатор сеанса, извлекает из внешних поставщиков состояния данные сеанса и затем привязывает эти данные к контексту вызовов запроса. Он также сохраняет данные состояния сеанса, когда обработка страницы завершается.

Однако важно понимать, что модуль SessionStateModule фактически не хранит данные сеанса. Вместо этого состояние сеанса сохраняется во внешних компонентах, которые называются поставщиками состояния:

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

Чтобы механизм состояния сеанса работал, клиент вместе с каждым запросом должен предоставлять соответствующий идентификатор сеанса. Финальным фрагментом данной головоломки является способ отслеживания этого идентификатора сеанса от одного запроса к другому. Это можно делать двумя способами:

С применением cookie-наборов. В этом случае идентификатор сеанса передается в специальном cookie-наборе (по имени ASP.NET_SessionId), который ASP.NET создает автоматически, когда используется коллекция сеанса. Он применяется по умолчанию и соответствует способу из более ранних версий ASP.

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

Использование состояния сеанса

Взаимодействовать с состоянием сеанса можно с помощью класса System.Web.SessionState.HttpSessionState, который на веб-странице ASP.NET доступен в виде встроенного объекта Session. Синтаксис для добавления элементов в эту коллекцию и их извлечения выглядит практически так же, как и синтаксис, который используется для добавления элементов в состояние представления страницы.

Например, вот как сохранить объект DataSet в памяти сеанса:

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

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

Если пользователь закрывает и заново запускает браузер.

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

Если сеанс завершается из-за отсутствия активности со стороны пользователя. По умолчанию сеанс автоматически завершается после 20 минут простоя.

Если программист завершает сеанс вызовом метода Session.Abandon().

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

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

В таблице ниже перечислены основные методы и свойства класса HttpSessionState:

Методы и свойства класса HttpSessionState

Метод или свойство Описание
Count Количество элементов в коллекции текущего сеанса
IsCookieless Указывает, как отслеживается этот сеанс: с помощью cookie-набора или с использованием измененных URL-адресов
IsNewSession Указывает, был ли данный сеанс только что создан для текущего запроса. Если в состоянии сеанса на текущий момент не содержится никакой информации, ASP.NET не будет беспокоиться ни об отслеживании сеанса, ни о создании cookie-набора сеанса. Вместо этого сеанс будет воссоздаваться заново при каждом запросе
Mode Предоставляет перечислимое значение, которое объясняет, как ASP.NET хранит информацию о состоянии сеанса. Этот режим хранения определяется на основе указанных в файле web.config конфигурационных настроек
SessionID Предоставляет строку с уникальным идентификатором сеанса для текущего клиента
StaticObjects Предоставляет коллекцию элементов сеанса, предназначенных только для чтения, которые были объявлены в global.asax с помощью дескрипторов . В основном эта технология не используется и является пережитком ASP-программирования; она поддерживается для обратной совместимости
Timeout Текущее количество минут, которое должно пройти, прежде чем текущий сеанс будет завершен при условии отсутствия запросов от клиента. Это значение может изменяться программно, что дает возможность при необходимости продлевать срок жизни коллекции сеанса для более важных операций
Abandon() Немедленно завершает текущий сеанс и освобождает все занятые им ресурсы памяти. Такая технология полезна на автономных страницах, поскольку позволяет освобождать ресурсы памяти сервера настолько быстро, насколько возможно
Clear() Удаляет все элементы сеанса, но не изменяет идентификатор текущего сеанса

Конфигурирование состояния сеанса

Сконфигурировать состояние сеанса можно с помощью элемента в файле web.config. Ниже показаны все доступные параметры настройки, которые можно применять:

Атрибуты сеанса подробно описаны в последующих разделах.

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

Off

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

InProc

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

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

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

StateServer

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

Выбрав режим StateServer, обязательно следует указать значение для параметра stateConnectionString. Эта строка сообщает TCP/IP-адрес компьютера, на котором запускается служба StateServer, и номер его порта (который определяется ASP.NET и который обычно изменять не нужно), что позволяет обслуживать службу StateServer на другом компьютере. Если не изменить значение этого параметра, использоваться будет локальный сервер (с адресом 127.0.0.1).

Разумеется, эта служба должна быть запущена, чтобы приложение могло с ней взаимодействовать. Проще всего это сделать с помощью консоли управления Microsoft (Microsoft Management Console). Выберите в меню Start (Пуск) пункт Programs Administrative Tools Computer Management (Все программы Администрирование Управление компьютером) или же откройте окно панели управления, щелкните на значке Administrative Tools (Администрирование), а затем на значке Computer Management (Управление компьютером). В появившемся диалоговом окне Computer Management (Управление компьютером) разверните узел Services and Applications (Службы и приложения) и щелкните на элементе Services (Службы). В правой части окна появится список служб: отыщите в нем службу по имени ASP.NET State Service:

Отыскав службу в списке, вы можете вручную запустить или остановить ее с помощью щелчка правой кнопкой мыши. Обычно имеет смысл сконфигурировать ОС Windows так, чтобы эта служба запускалась автоматически. Для этого щелкните на имени службы правой кнопкой мыши, в появившемся контекстном меню выберите пункт Properties (Свойства). После этого в списке Startup Type (Тип запуска) выберите значение Automatic (Автоматически), как показано на рисунке ниже. Далее щелкните на кнопке Start (Запустить), чтобы запустить эту службу немедленно.

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

SQLServer

Это значение заставляет ASP.NET использовать для хранения информации о сеансе базу данных SQL Server, применяя параметры, определенные в атрибуте sqlConnectionString. Такой способ управления состоянием является наиболее удобным, но пока что самым медленным. Чтобы его можно было использовать, на сервере должна быть установлена система SQL Server.

Установка значения для атрибута sqlConnectionString выполняется по схеме, подобной той, что применяется для получения доступа к данным ADO.NET. В целом это подразумевает указание источника данных (адреса сервера), имени пользователя и пароля, если только не используется интегрированная система безопасности SQL.

Вдобавок также должны быть установлены специальные хранимые процедуры и временные базы данных сеансов. Эти хранимые процедуры будут отвечать за сохранение и извлечение данных сеанса. В состав ASP.NET входит утилита командной строки, позволяющая выполнять эту задачу автоматически. Называется она aspnet_regsql.exe и находится в каталоге c:\Windows\Microsoft.NET\Framework\[Версия].

Удобнее всего запускать ее в окне командной строки Visual Studio (выберите в меню Start (Пуск) пункт Programs Microsoft Visual Studio 2012 Visual Studio Tools Visual Studio 2012 Command Prompt. Затем можно сразу же вводить команду aspnet_regsql.exe независимо от того, в каком каталоге она открыта.

Утилита aspnet_regsql.exe может применяться для решения нескольких связанных с базами данных задач. Чтобы использовать ее для создания базы данных с хранилищем сеансов, нужно указать параметр -ssadd. Кроме того, параметр -S позволяет указать имя сервера базы данных, а параметр -Е — что для подключения к этой базе данных должна использоваться учетная запись текущего пользователя Windows.

Ниже показана команда, которая создает базу данных для хранения данных сеанса на текущем компьютере, используя для нее стандартное имя ASPState:

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

После создания базы данных состояния сеанса необходимо указать ASP.NET ее использовать, внеся соответствующие изменения в раздел файла web.config. Если для хранения информации о состоянии сеанса была создана база данных ASPState (это принято по умолчанию), тогда предоставлять ее имя в разделе не нужно. Вместо этого следует указать место размещения сервера и тип аутентификации, который ASP.NET должна применять для подключения к этому серверу:


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

Для удаления базы данных ASPState используйте параметр -ssremove.

Обычно при управлении состоянием с помощью SQL Server по-прежнему действует стандартный параметр тайм-аута состояния сеанса. Причина в том, что утилита aspnet_regsql.exe также создает для SQL Server новое задание по имени ASPState_Job_DeleteExpiredSessions. До тех пор, пока работает служба SQLServerAgent, это задание будет выполняться каждую минуту.

Кроме того, при каждом перезапуске сервера SQL Server, независимо от значения тайм-аута сеанса, будут удаляться таблицы данных состояния. Дело в том, что таблицы информации о состоянии создаются в базе данных tempdb, которая является всего лишь временным хранилищем. Если такое поведение не подходит, можно указать утилите aspnet_regsql.exe установить в базе данных ASPState постоянные таблицы данных состояния. Для этого понадобится использовать параметр -sstype p (где p означает «persisted» (постоянный)). Ниже показана модифицированная версия предыдущей команды:

Теперь записи сеанса будут оставаться в базе данных даже в случае перезапуска SQL Server.

И, наконец, последний вариант: утилиту aspnet_regsql.exe также можно применять для создания таблиц данных состояния в какой-то другой базе данных (отличной от ASPState). Для этого применяется параметр -sstype c (где c означает «custom» (специальный)) и указывается имя базы данных в параметре -d:

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

В случае использования специальной базы данных также потребуется выполнить две конфигурационные настройки в разделе файла web.сonfig. Во-первых, необходимо установить атрибут allowCustomSqlDatabase в true. Во-вторых, понадобится добавить в строку соединения параметр InitialCatalog с именем используемой базы данных. Ниже показан должным образом настроенный элемент :

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

Custom

Выбор специального (Custom) режима требует указания используемого поставщика хранилища данных о состоянии сеанса с помощью атрибута customProvider. В атрибуте customProvider может быть задано как имя класса, являющегося частью веб-приложения и хранящегося в каталоге App_Code, так и имя класса, входящего в состав скомпилированной сборки и хранящегося в каталоге Bin или в глобальном кэше сборок (GAC).

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

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

Сжатие

В ASP.NET доступно средство сжатия, которое позволяет сократить размер сериализируемых данных сеанса. Если установить атрибут enableCompression в true, данные сеанса перед отправкой за пределы процесса будут сжиматься (с использованием класса System.IO.Compression.GZipStream). Параметр enableCompression действует только при использовании внепроцессного хранилища состояния сеанса, поскольку только в такой ситуации данные сериализируются.

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

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

При сохранении данных состояния сеанса данных на другом компьютере. В некоторых веб-приложениях с высокой степенью масштабируемости состояние сеанса сохраняется за пределами процесса (обычно в базе данных SQL Server) или на отдельном компьютере. Из-за этого среда ASP.NET должна передавать информацию сеанса туда и обратно через сетевое соединение. Очевидно, что при таком проектном решении показатели производительности будут значительно ниже, чем при сохранении состояния сеанса на компьютере веб-сервера. Однако для некоторых веб-приложений, с высоким трафиком и большими потребностями в плане сохранения данных состояния сеанса это решение все равно может быть лучшим компромиссом.

В первом случае сжатие позволяет жертвовать ресурсами ЦП во имя экономии памяти веб-сервера, а во втором — ради сокращения нагрузки на сетевое соединение. Степень сжатия существенно варьируется в зависимости от типа данных, но во время тестирования клиентам Microsoft удавалось достигать сокращения размеров данных на 30-60% , что гарантирует значительный выигрыш в производительности.

Cookieless

Параметр Cookieless может быть установлен в любое из значений перечисления HttpCookieMode. С помощью атрибута cookieName можно указать имя, используемое для cookie-набора. Если оно не указано, для имени cookie-набора принимается значение по умолчанию, которое выглядит как ASP.NET_SessionId.

Значения, доступные в перечислении HttpCookieMode

Значение Описание
UseCookies Cookie-наборы используются всегда, даже если браузер или устройство не поддерживает их или если они были отключены. Это значение устанавливается по умолчанию. Если устройство не поддерживает cookie-наборы, информация сеанса будет утрачиваться при последующих запросах, потому что каждый запрос будет получать новый идентификатор
UseUriCookie Cookie-наборы не используются никогда, независимо от возможностей браузера или устройства. Вместо этого идентификатор сеанса сохраняется в URL-адресе
UseDeviceProfile ASP.NET решает, какие сеансы использовать (с поддержкой cookie-наборов или без), анализируя содержимое объекта BrowserCapabilities. Недостаток такого подхода заключается в том, что этот объект указывает, что устройство должно поддерживать: он не учитывает того факта, что пользователь мог отключить cookie-наборы в браузере, который в принципе их поддерживает
AutoDetect ASP.NET пытается определить, поддерживает ли браузер cookie-наборы, пробуя установить и извлечь cookie-набор. Эта широко используемая технология позволяет точно определить, когда браузер поддерживает cookie-наборы, но это средство было отключено, указывая ASP.NET применять режим без поддержки cookie-наборов

Ниже приведен пример принудительного применения режима без поддержки cookie-наборов (что удобно для целей тестирования):

В режиме без поддержки cookie-наборов идентификатор сеанса будет автоматически вставляться в URL-адрес. Получив запрос, ASP.NET будет удалять идентификатор, извлекать коллекцию сеанса и направлять запрос в соответствующий каталог. Измененный URL-адрес показан ниже:

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

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

По умолчанию ASP.NET допускает повторное использование идентификатора сеанса. Например, если делается запрос и строка запроса содержит просроченный сеанс, ASP.NET создает новый сеанс и использует этот же идентификатор сеанса. Проблема в том, что идентификатор сеанса может случайно появиться в каком-то публичном месте, например, на странице результатов в поисковой службе. Это может привести к тому, что множество пользователей получат доступ к серверу с одним и тем же идентификатором сеанса и затем присоединятся к одному и тому же сеансу с теми же самыми разделяемыми данными.

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

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

Чтобы выяснить, используется ли в текущий момент сеанс без cookie-наборов, необходимо проверить свойство IsCookieless объекта Session.

Timeout

Еще одним важным параметром настройки состояния сеанса в файле web.config является Timeout. Он указывает количество минут, в течение которых ASP.NET будет находиться в режиме ожидания (не получая запрос), прежде чем завершит сеанс:

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

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

Обеспечение безопасности состояния сеанса

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

Существует несколько подходов, позволяющих обойти эту проблему. Наиболее распространенный из них — воспользоваться специальным модулем сеанса, выполняющим проверку на наличие изменений в IP-адресе клиента. Однако единственным действительно безопасным подходом является разрешение доступа к cookie-наборам сеанса только из тех разделов веб-сайта, где используется SSL-шифрование. В таком случае cookie-набор сеанса шифруется и, следовательно, становится бесполезным на других компьютерах.

Если решено воспользоваться этим подходом, также имеет смысл пометить cookie-набор как безопасный, чтобы он пересылался только через SSL-соединения. Это не позволит пользователям изменять URL-адрес с https:// на http:// и, следовательно, пересылать cookie-набор без SSL-шифрования. Ниже показан необходимый код:

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

При использовании сеансов без cookie-наборов существует еще одна потенциальная угроза нарушения системы безопасности. Даже если идентификатор сеанса зашифрован, применив прием социальной инженерии, сообразительный пользователь может вынудить другого пользователя подключиться к определенному сеансу. Все, что злоумышленнику понадобится — это подсунуть другому пользователю URL-адрес с действительным идентификатором сеанса. Щелкнув на ссылке, этот пользователь сразу же подключится к такому сеансу. Хотя с этого момента идентификатор сеанса будет защищаться, атакующему уже известно, какой идентификатор сеанса используется, поэтому он сможет позже взломать этот сеанс.

Чтобы снизить возможность такой атаки, необходимо выполнить ряд определенных шагов. Во-первых, при использовании сеансов без cookie-наборов всегда устанавливайте атрибут regenerateExpiredSessionId в true. Это не позволит злоумышленнику предоставлять просроченный идентификатор сеанса. Во-вторых, явно прекращайте текущий сеанс перед входом в систему нового пользователя.

Илон Маск рекомендует:  Что такое код domnode >node_name

Pages Section. Enable Session State Свойство

Определение

Возвращает или задает значение, определяющее состояние сеанса, который может быть включен, отключен или доступен только для чтения. Gets or sets a value that specifies whether the session state is enabled, disabled, or read-only.

Значение свойства

Одно из значений свойства EnableSessionState, определяющего состояние сеанса, который можно быть включен, отключен или доступен только для чтения. One of the values for the EnableSessionState property, which specifies whether the session state is enabled, disabled, or read-only. Значением по умолчанию является True, отражающее включенное состояние сеанса. The default is True, which indicates that session state is enabled.

Исключения

Значение не является допустимым значением перечисления PagesEnableSessionState. The value is not a valid PagesEnableSessionState enumeration value.

Примеры

В следующем примере кода показано, как использовать свойство EnableSessionState. The following code example shows how to use the EnableSessionState property.

Что такое код asp @enablesessionstate

Опубликовано: Октябрь 2020


Возвращает или задает значение, указывающее, является ли состояние сеанса включено, отключено или только для чтения.

Пространство имен: System.Web.Configuration
Сборка: System.Web (в System.Web.dll)

Значение свойства

Одно из значений для свойство, которое указывает, является ли состояние сеанса включено, отключено или только для чтения. Значение по умолчанию — True, указывает, что состояние сеанса включено.

Значение не является допустимым PagesEnableSessionState значение перечисления.

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

Почему ASP.NET получить доступ к серверу состояний даже когда страница в EnableSessionState = «False», но только на сайте VB.NET, а не C # сайт?

Наш сайт использует наше собственное несерийное управление состоянием сеанса ASP.NET отдельно от состояния сеанса. Но из — за несколько специальных страниц с помощью служб отчетов SQL Server, мы также должны включить состояние сеанса ASP.NET. Поскольку мы находимся в балансировкой нагрузки окружающей среды, мы включили в ASP.NET состояние сервера (aspnet_state.exe или «Нет в процессе Mode») на отдельной серверной машине.

Сегодня я заметил, что, когда мы временно обрушили машина работает Государственная служба в нашей среде Dev, сайт Dev перестал работать ( «Невозможно сделать запрос о состоянии сеанса в состояние сеанса сервера.») Это несмотря на то, EnableSessionState = «False» на странице загружается.

Почему ASP.NET необходимо подключить к государственной службе при обслуживании запроса на страницу, которая не использует состояние сеанса? Это, кажется, случается, даже если страница не использует мастер-страницу, страничный или любые пользовательские элементы управления. Я просмотрел весь наш код-позади, чтобы гарантировать, что мы никогда не программно повторного включения состояния сеанса или попытки доступа к нему.

— EDIT после более НЕИСПРАВНОСТЕЙ —

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

Что такое код asp @enablesessionstate

Данные советы вводят в проблему повышения производительности работы приложений, использующих технологии Microsoft Active Server Pages (ASP) и Visual Basic Scripting Edition (VBScript). Большинство из них были многократно обсуждены и c успехом проверены на практике и будут интересны как новичкам в программировании ASP и VBScript, так и тем, кто уже имеет опыт работы с этими технологиями. При подготовке советов был использованы материалы c веб-сайта корпорации Microsoft Corp. (http://www.microsoft.com) и материалы конференций Relib.com (http://www.relib.com)

Совет 1: Кэшируйте часто используемые данные на сервере

Типичная ASP-страница получает данные из базы данных и затем выводит их в формате HTML. Независимо от скорости работы вашей базы данных, получение данных из памяти сервера будет намного быстрее, чем обработка sql-запроса к конечной базе данных. Получение данных, сохраненных на локальном жестком диске сервера, также обычно быстрее, чем получение информации из БД. Поэтому одним из основных путей увеличения скорости работы вашей ASP-страницы является кэширование часто используемой информации в памяти или на жестком диске.

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

Данные, которые изменяются не часто, будут хорошим кандидатом для кэширования, потому что вам не надо будет волноваться относительно их синхронизации через какое-то время с конечной базой данных. Выпадающие списки (сombo-box), таблицы ссылок, пункты меню, и переменные конфигурации сайта (включая имена DSN, адреса IP и URL) — первые кандидаты для хранения в кэше. Заметьте, что вы можете кэшировать представление данных много быстрее, нежели данные сами себя. Если ASP-страница изменяется не так часто и ее временный кэш будет весьма внушительным (например, полный каталог изделий фирмы), попробуйте использовать сгенерированные HTML-страницы, чем каждый раз загружать сервер генерацией ASP-страниц.

Совет 2: Кэшируйте часто используемые данные в объектах Application или Session

Объекты Application и Session служат для хранения данных в памяти, значения которых могут быть доступны между несколькими HTTP-запросами (в отличие от обычных переменных, чьи значения доступны только в теле одной ASP-страницы). Данные объекта Session доступны только одному пользователю (в течении его сессии), в то время как данные Application доступны всем пользователям веб-сайта. Поэтому часто перед разработчиком возникает вопрос: в каком из объектов сохранять часто используемые данные. Обычно, для инициализации переменных этих объектов используются процедуры файла Global.asa — Application_OnStart() или Session_OnStart() соответственно. Если в вашем Global.asa еще нет этих процедур, то вы можете добавить их сами или инициализировать переменные, когда это будет необходимо. Примером может быть следующая процедура, использующая Application для хранения значений многократно использующейся переменной EmploymentStatusList. Процедура проверяет существование данных в EmploymentStatusList и при необходимости расчитывает их заново:

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

Если полученный массив будет часто использоваться, тогда лучше хранить его сразу в виде HTML-списка, чем массив, которое каждый раз нужно преобразовывать в HTML:

Совет 3: Кэшируйте данные на диске веб-сервера

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

Заметьте, что при измерении производительности одиночной ASP-страницы, получение данных с диска может не всегда быть быстрее, чем получение равноценных данных из БД. Но «файловое» кэширование уменьшает загрузку БД и сети, а при высокой загрузке БД до, значительно улучшит общую производительность после. Кэширование может быть очень эффективно при кэшировании результатов сложных запросов (например, соединение таблиц), трудоемких процедур сохранения, больших наборов записей. Чтобы убедится, насколько выгодным будет это решение требуется протестировать различные схемы сохранения.

ASP и COM обеспечивают несколько инструментальных средств для создания схем кэширования на диске. Функции набора записей ADO Save() и Open() сохраняют и загружают recordset c диска. Используя эти методы вы можете переписать код из прошлого совета, заменяя запись в объект Application на метод Save() для записи в файл.

Есть несколько других компонентов, которые работают с файлами:

  • Scripting.FileSystemObject позволяет создавать, читать и записывать файл.
  • MSXML, MicrosoftR XML parser поддерживает сохранение и загрузку XML-документов.
  • Объект LookupTable (например, используемый на MSN.com) — лучший выбор для загрузки простых списков с диска.

Наконец, рассмотрите вопрос принудительного кэширования информации на диске. Сгенерированный HTML-код может быть сохранен на диске как .htm или .asp файл; гиперссылки могут указывать прямо на этот файл. Вы можете автоматизировать процесс генерации HTML, используя коммерческие инструментальные средства типа XBuilder или средства публикации в Интернет, входящие в MicrosoftR SQL ServerT. Кроме того, при помощи директивы #include можно включать отдельные HTML-части в файл ASP или читать HTML-файл с диска используя FileSystemObject. Например, на начальной странице веб-сайта Relib.com (http://www.relib.com/index.asp) приводятся 2 списка последних тем обсуждения двух дискуссионных форумов этого сайта. Отобразить эти списки можно при помощи создания двух наборов записей ADO при каждом обращении к данной странице или, следуя данному совету, сохранить их однажды в виде HTML-файла list.inc, а затем включать в index.asp:

Второй путь работает значительно быстрее.

Совет 4: Избегайте кэшировать медленные компоненты в объектах Application или Session

Несмотря на то, что кэшированиe данных в объектах Application или Session может быть хорошей идеей, кэширование COM-объектов может иметь серьезные ловушки. Занесение наиболее используемых COM-объектов в объекты Application или Session часто соблазняет, но, к сожалению, много COM-объектов, включая все, написанные в Visual Basic 6.0 или ранее, могут вызывать серьезные критические проблемы после сохранения в объектах Application или Session.

В частности, любой компонент, который выполняется медленно, вызовет критические проблемы когда кэшируется в объектах Session или Application. Быстрый (проворный non-agile) компонент — компонент, помеченный ThreadingModel=Both, который объединен Free-threaded marshaler (FTM), или — компонент, помеченный ThreadingModel=Neutral. (Neutral — новая модель в WindowsR 2000 and COM+). Следующие компоненты не проворны:

  • Free-threaded components.
  • Apartment-threaded components.
  • Single-threaded component.
  • Configured components (библиотека Microsoft Transaction Server (MTS)/COM+ и серверные приложения) не проворны пока они Neutral-threaded. Apartment-threaded components и другие не проворные компоненты хорошо работают в пределах страницы (т.е. создаются и разрушаются в пределах одной ASP-страницы).

В IIS 4.0 компонент, отмеченный ThreadingModel=Both выполняется быстро. В IIS 5.0 уже не так достаточно. Компонент не должен только быть отмечен как Both, он должен также объединен FTM.

IIS выполняет проверку компонентов, но если вы хотите ее отменить (т.е. хотите позволить непроворным компонентам быть сохраненными в объектах Application или Session), вы можете установить AspTrackThreadingModel в metabase в значение True. Но это (изменение AspTrackThreadingModel) не рекомендуется.

IIS 5.0 выдаст сообщение об ошибке, если Вы пытаетесь сохранить непроворный компонент, созданный с использованием Server.CreateObject, в объекте Application. Вы можете обойти это, используя в Global.asa, но это также не рекомендуется, поскольку это ведет к проблемам (очереди и сериализация), объясняемым ниже.

Что же все-таки неправильно если вы кэшируете непроворные компоненты? Непроворный компонент, кэшируемый в объекте Session блокирует Session от других рабочих потоков (thread) ASP. ASP обслуживает пул (контейнер) рабочих потоков, запрашиваемых другими сервисами. Обычно, новый запрос обрабатывается первым доступным потоком. Если Session блокирована, то запрос должен ждать поток, когда он станет доступным. Проведем аналогию, которая поможет понять эту ситуацию: вы идете в магазин, выбираете несколько булок, и платите за них в кассе #3. Всякий раз, после того как вы выбрали булки в том магазине, вы всегда оплачиваете их в кассе #3, даже в том случае, когда в других кассах короче очередь или даже вообще нет покупателей.

Сохранение непроворных компонентов в объект Application накладывает столь же негативный эффект на производительность. ASP создает специальный поток для выполнения меделенных компонентов в пределах Application. Это имеет два последствия: все запросы выстраиваются в очередь к этому потоку и все запросы сериализуются. Выстраивание в очередь означает, что параметры были сохранены в общедоступной области памяти; запросы переключаются к специальному потоку; метод компонента выполнен; результаты выстраиваются в общедоступную область. Сериализация (преобразование в последовательную форму) означает, что все методы выполняются в одно время. Для двух различных потоков ASP не возможно одновременное выполнение методов общедоступного компонента. Это уничтожает многопотоковость (параллелизм), особенно на мультипроцессорных системах. Хуже всего то, что все непроворные компоненты в пределах Application совместно используют один поток («Host STA»), так что негативные результаты сериализации налицо.

Смущены? Есть некоторые общие правила. Если Вы пишете объекты в Visual Basic (6.0 или ранее), не храните их в объектах Application или Session. Если вы не знаете потоковую модель объекта, не храните его в кэше. Вместо кэширования где-либо непроворных объектов, вы должны создать и удалить их на каждой странице. Объекты выполнятся непосредственно в рабочем потоке ASP и не будет никакой очереди или сериализации. Производимость будет адекватна, если COM-объекты запущены под IIS и если они не используют много времени, чтобы инициализироваться и уничтожаться. Заметьте, что однопотоковые (single-threaded) объекты не должны использоваться этот путь. Будьте внимательным — VB может создавать однопотоковые объекты! Если вы используете однопотоковые объекты, этот путь (типа таблицы Microsoft Excel) не рассчитывает на высокую производительность.

Наборы записей (recordset) ADO могут безопасно кэшироваться когда ADO отмечен как Free-threaded. Чтобы сделать ADO как Free-threaded используйте файл Makfre15.bat, который обычно зафиксирован в каталоге \\Program Files\Common Files\System\ADO.

Предупреждение: ADO не должен быть Free-threaded, если вы используете Microsoft Access в качестве БД. Набор записей ADO должен быть также вообще отсоединен, если вы не можете управлять конфигурацией ADO на вашем веб-сайте.

Совет 5: Не кэшируйте соединение БД в объектах Application или Session

Кэширование соединений ADO — обычно является плохой стратегией при разработке ASP-сайта. Если один объект Connection сохранен в объекте Application и используется на всех страницах, то все страницы будут бороться за использование этого соединения. Если объект Connection сохранен в ASP-объекте Session, то соединение БД будет создано для каждого пользователя. Это создает излишнюю загрузку веб-сервера и БД.

Вместо кэширования соединений БД, создавайте и уничтожайте объекты ADO на каждой ASP странице, которая использует ADO. Это эффективно, потому что IIS имеет встроенное подключение БД. Более точно, IIS автоматически допускает объединение подключений OLEDB и ODBC. Это гарантирует, что создание и уничтожение связей на каждой странице будут эффективны.

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

Совет 6: Разумное использование объекта Session

Теперь, когда в предыдущих советах были раскрыты достоинства кэширования данных в объектах Applications и Sessions, вам предлагается пытаться избегать использования объекта Session. Сессии имеют несколько ловушек когда используются на загруженных сайтах. Под «загруженными» имеются ввиду сайты с сотнями запрашиваемых страниц в секунду или тысячами пользователей одновременно. Этот совет также важен для сайтов, которые должны масштабироваться горизонтально — т.е. те сайты, которые используют несколько серверов для распределения нагрузки и обеспечения отказоустойчивости при сбоях. Для меньших сайтов, типа intranet-сайтов, преимущества применения Sessions все же перевешивают.

Обобщая, ASP автоматически создает Session для каждого пользователя, который обращается к веб-серверу. Каждая сессия занимает приблизительно 10 Кб памяти (сверх любых данных, сохраненных в Session) и немного замедляет выполнение всех запросов. Сессия остается действующей до окончания таймаута (timeout), обычно 20 мин.

Но самая большая проблема при использовании сессий — это не производительность, а расширяемость. Сессии не охватывают все задействованные веб-сервера; как только Session была создана на одном сервере ее данные остаются там. Это означает, что если вы используете сессии на мультисерверном веб-сайте, вы должны придумать стратегию для обработки запросов каждого пользователя, которые должны быть всегда направлены на сервер, на котором существует сессия этого пользователя. Это называется «застреванием» пользователя на сервере (или «липкой сессией»).

Объект Application также не охватывает все сервера: если вам нужно совместно использовать и обновлять данные Application через веб-сервера, вам нужно использовать конечную базу данных. Однако неизменяемые (read-only) данные Application все же полезны на мультисерверных сайтах.


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

Если же вы не используете Session, то убедитесь, что отключили их. Это можно сделать посредством Internet Services Manager (см. документацию по ISM). Но если вам все-таки необходимо использовать сессии, то есть несколько путей уменьшить их удары про производительности.

Вы можете переместить содержимое, которое не требует сессий (например, страницы help и т.д.) в отдельное ASP-приложение, у которого сессии выключены. Кроме того, на страницах, где объект Session не используется, применяйте следующую директиву, помещещаемую вверху страницы:

Одна из основных причин ее применения — то, что Session создает интересную проблему в случае использования фрэймов (frameset). ASP гарантирует, что в любое время будет выполняться только один запрос от Session. Это делается для того, чтобы при одновременном запросе одним пользователем нескольких страниц, только один ASP-запрос был обработан сессией, что помогает избежать проблем многопоточного доступа к объекту Session. К сожалению, в результате этого все страницы в frameset будут загружаться последовательно, а не одновременно, и пользователю придется продолжительное время ждать полной загрузки. Мораль этой истории: если вы не уверены, что с использованием фрэймов и Session ваше приложение правильно работает, то используйте:

Альтернативой использованию объекта Session являются многочисленные параметры управления Session. При передаче малых объемов данных (менее 4 Кб) обычно рекомендуется использовать Cookies, переменные QueryString и скрытые (h >Если в вашем приложении используется много функций VBScript или JScript, то зачастую производительность можно улучшить поместив этот код в откомпилированный COM-объект. Обычно откомпилированная программа выполняется значительно быстрее, чем интерпретируемый код, поэтому откомпилированные COM-объекты будут работать более эффективно, чем вызываемые методы скрипта.

Выделение (инкапсуляция) кода в COM-объект имеет следующие преимущества (не считая производительности):

  • COM-объекты хороши для логического представления структуры приложения.
  • COM-объекты позволяют многократное использование одного кода.
  • Много разработчиков находят код, написанный в VB, C++ или Visual J++ проще в отладке, чем ASP.

Но наряду с, казалось бы, неоспоримыми достоинствами COM-объекты имеют и недостатки, среди которых — время разработки и потребность в различных навыках программирования. Будьте уверены, что инкапсуляция в малых ASP-приложениях может вызвать скорее убытки, чем прибыль. Обычно это случается, когда маленькое количество ASP-кода переносится в объект COM. В этом случае накладные расходы от создания и вызова этого объекта перевешивают выгоду от использования интерпретируемой программы. Определить наиболее выигрышную комбинацию для производительности — использование сценариев ASP или COM-объектов — можно только методом проб и ошибок. Заметим, что Microsoft значительно улучшила ASP-сценарии и производительность ADO в Windows 2000/IIS 5.0 по сравнению с Windows NT 4.0/IIS 4.0. Таким образом, преимущество откомпилированного кода над кодом ASP уменьшилось с введением IIS 5.0 и ваше приложение должно работать быстрее, по сравнению с четвертой версией IIS.

Совет 8: Объявляйте переменные поздно, а удаляйте рано

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

Соединения (Connection) ADO и рекордсеты — первостепенные кандидаты для этой оптимизации. Использовав recordset или сonnection для отображения данных сразу же удаляйте эти переменные из памяти, не дожидаясь конца страницы. Не позволяйте рекордсету или соединению остаться незакрытыми.

Например, если вы создаете соединение и открываете набор записей следующим образом:

то закройте их вот так:

Любые другие переменные Microsoft VBScript также лучше устанавливать в Nothing.

Совет 9: Out-of-process как компромисс между производительностью и надежностью

И ASP и MTS/COM+ имеют параметры конфигурации, которые позволяют вам выбрать альтернативу между надежностью и производительностью. Вы должны сделать разумный выбор при разработке ваших ASP-приложений.

Работа ASP-приложений может быть сконфигурирована одним из трех путей. В IIS 5.0 введен термин «уровень изоляции» (isolation level), описывающий эти пути, и который делится на три уровня — Low (низкий), Medium (средний), и High (высокий):

Low Isolation. Поддерживается во всех версиях IIS и самый быстрый. Он выполняет ASP в Inetinfo.exe, который является первичным процессом IIS. Если ASP-приложение дает сбой, то нагрузка ложится на IIS. (Чтобы перезапутить IIS под IIS 4.0 вебмастер должен был вести мониторинг сайта, используя инструменты типа InetMon, и рестартовать его командным файлом, если на сервере произошел сбой. В IIS 5.0 введена более надежная функция рестарта, которая автоматически перезапускает сервер в случае сбоя.)

Medium Isolation. Этот новый уровень, впервые введенный в IIS 5.0, называют out-of-process, т.к. ASP выполняется вне процесса IIS. В Medium Isolation все приложения ASP сконфигурированы для выполнения как среднеразделенный процесс. Это уменьшает число процессов, требуемых для загрузки нескольких ASP-приложений out-of-process. В IIS 5.0 уровень Medium Isolation установлен по-умолчанию.

High Isolation. Поддерживающийся в IIS 4.0 и IIS 5.0 уровень High Isolation также выполняется out-of-process. Если в ASP произошел сбой, то с веб-сервером ничего не случится — ASP-приложение автоматически перезапускается со следующим запросом ASP. В High Isolation, каждое ASP-приложение сконфигурировано для выполнения в собственном участке памяти, что защищает приложения ASP от друг друга (отсюда и название — «высокая изоляция»). Недостаток этого — требование раздельных процессов для каждого ASP-приложения.

Вы спросите, который уровнь лучше? В IIS 4.0 выполнение out-of-process сказывалось довольно негативно на производительности. В IIS 5.0 было проделано много работы для уменьшения последствий от запущенных out-of-process ASP-приложений. Фактически в большинстве испытаний ASP-приложения, запущенные out-of-process под IIS 5.0, выполняются быстрее, чем под IIS 4.0. Независимо от этого, Low Isolation все еще предоставляет лучшую производительность на обеих платформах. Однако, вы не увидите большой выгоды от Low Isolation, если ваш веб-сервер имеет низкую нагрузку. Поэтому, вам не стоит устанавливать этот уровень, до тех пор, пока ваш сервер не будет выполнять запросы в сотни или даже тысячи страниц в секунду. Как всегда, испытание с различными конфигурациями и определяет наиболее лучший выбор.

Заметим, что когда вы выполняете ASP-приложения out-of-process (уровни Medium или High), они выполняются в MTS под NT4 и COM+ под Windows 2000. Т.е. под NT4 они выполняются в Mtx.exe, а под Windows 2000 они выполняются в DllHost.exe. Вы можете увидеть эти процессы запустив Администратор Задач (Task Manager). Вы можете также увидеть как IIS компонует пакеты MTS или приложения COM+ для out-of-process приложений ASP.

Компоненты COM также имеют три параметра конфигурации, хотя они и не полностью аналогичны параметрам настройки ASP. Компоненты COM могут быть: «неконфигурированными» (unconfigured), настроенными как библиотечные или серверные приложения. «Неконфигурированные» — т.е. компонент не зарегистрирован с COM+. Такой компонент будет выполниться в памяти вызывающего процесса, т.е. «in-process» («в процессе»). Библиотечные приложения (Library Applications) также выполняются in-process, но имеют выгоду от сервисов COM+, включая защиту, транзакции и контекстную поддержку. Серверные приложения выполняются в собственной памяти процесса.

Вы сможете увидеть весьма небольшую выгоду неконфигурированных компонентов над библиотечными приложениями. И, вероятно, большую производительность библиотечных приложений над серверными. Это все потому, что библиотечные приложения выполняются в том же самом процессе, что и ASP, в то время как серверные приложения выполняются в их собственном процессе — межпроцессорные запросы более трудоемки, чем работа в in-process (например, при обмене данными recordset между процессами, все данные должны быть скопированы из одного процесса в другой).

Так что же все-таки использовать?

Если вам требуются конфигурации с разумными долями реализации производительности и надежности, то советуем вам следующее: под IIS 4.0 используйте Low Isolation level и MTS Server Packages, под IIS 5.0 используйте Medium Isolation level и COM+ Library Applications. Но учтите, что данный совет — очень общая рекомендация. Например, хостинговые компании обычно устанавливают Medium или High Isolation level, тогда как множество веб-серверов могут работать в Low Isolation. Так что, лучше всего попробовать самому и решить, которая конфигурация непосредственно для вас наилучшим образом выполняет ваши потребности.

Совет 10: Используйте директиву Option Explicit

Используйте директиву Option Explicit в ваших .asp файлах. Расположенная в самом верху .asp файла, она заставляет разработчика объявлять все переменные, которые он использует. Многие программисты считают, что это позволяет быстрее отлаживать приложения, исключая, таким образом, ошибки в написании имен переменных и невнимательное создание новых переменных (например, MyXLMString=. вместо MyXMLString=).

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

Таким образом, использование директивы Option Explicit гарантирует, что все используемые переменные объявлены и доступ к ним будет максимально быстрым.

Совет 11: Используйте локальные переменные в подпрограммах и функциях

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

Совет 12: Копируйте частоиспользуемые данные в переменные

При вызове COM в ASP, вы должны копировать частоиспользуемые данные объекта в переменные ASP-скрипта. Это сократит количество запросов методов COM, которые являются относительно трудоемкими по сравнению с обращением к переменным самого скрипта. При вызове объектов Collection и Dictionary этот совет также сокращает время запросов.

Вообще, если вы пользуетесь объектом данных больше, чем однажды, поместите данные в переменную ASP-скрипта. Главной целью этой оптимизации являются переменные объекта Request (Form и QueryString). Например, на вашем веб-сайте через QueryString передается переменная UserID. Предположите, что этот UserID упомянут дюжину раз на каждой странице. Вместо вызова Request(«UserID») 12 раз, поместите этот UserID в какую-либо переменную наверху ASP страницы и затем используйте эту переменную (а не Request) внутри страницы. Это упразднит 11 COM-запросов!

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

Когда этот код выполняется, происходит следущее:

  1. Переменная Foo получена как глобальный объект.
  2. Переменная bar получена как член Foo. Это оказывается запросом COM-метода.
  3. Переменная blah получена как член Foo.bar. Это также оказывается запросом COM-метода.
  4. Переменная qaz получена как член foo.bar.blah. Да, это также оказывается запросом COM-метода.
  5. Вызовите Foo.bar.blah.quaz(1). Еще один запрос COM-метода. Представляете?
  6. Сделайте шаги от 1 до 3 снова, чтобы получить baz. Система не знает, изменил запрос к qaz модель объекта, так что шаги 1 до 3 должны быть выполнены снова, чтобы получить baz.
  7. Получите baz как член Foo.bar.blah.
  8. Сделайте шаги от 1 до 3 снова и получите zaq.
  9. Сделайте шаги от 1 до 3 уже в другой раз и получите abc.

Как видите это ужасно неэффективно (и медленно). Быстрый способ — написать этот код в VBScript: ,pre> Set myobj = Foo.bar.blah ‘Объявляем blah однажды! Myobj.baz = myobj.qaz(1) If Myobj.zaq = Myobj.abc Then ‘.

Если вы используете VBScript 5.0, то можете использовать выражение With:

Совет 13: Избегайте использования переопределяемых массивов

Пытайтесь избегать переопределяемых (Redim) массивов. Если ваш сервер ограничен физическим размером памяти, то намного лучше сразу установить размер массива в наибольшее значение, которое может быть, либо привести размер к оптимальному и переопределять по мере необходимости. Это, конечно, не означает, что вы должны сделать ваш массив размером в пару мегабайтов, если вы знаете, что столько вам никогда не понадобится.

Пример ниже показывает использование беспричинного использования Dim и Redim.

Есть ли в этом смысл? Гораздо было бы лучше использовать для инициализации массива изначально известный размер (в этом случае 5), чем каждый раз переопределять его. Определяя массив сразу вы будете тратить впустую небольшое количество памяти (если не все элементы массива используются), но выгодой будет скорость работы вашего скрипта.

Совет 14: Используйте буферизацию Response

Вы можете буферизировать целую страницу, включив «response buffering». Это минимизирует количество записей в браузер и, таким образом, улучшит производительность. Каждая запись имеет много непроизводительных издержек (и в самом IIS и в том количестве данных, посланных по проводам), так что меньшее количество записей будет лучше. TCP/IP работает намного более эффективно когда возможно посылать несколько больших блоков данных, чем при пересылке многочисленных маленьких блоков (из-за медленного начала процесса пересылки и сложных алгоритмов проверки).

Есть два пути использования «response buffering». Первый путь — вы можете включить response buffering для приложения, взятого в целом, используя Internet Services Manager. Это рекомендуемый подход, поэтому response buffering включен по-умолчанию для новых ASP-приложений в IIS 4.0 и IIS 5.0. Второй путь — вы можете активировать буферизацию, поместив следующую линию кода вверху ASP-страницы:

Эта линия кода должна быть выполнена прежде, чем любые данные response был записаны в браузер (т.е. прежде, чем появится любой код HTML в ASP-скрипте и прежде, чем были установлены любые Cookies, используя Response.Cookies). Вообще, лучше включить response buffering, как указано в первом случае. Это позволит вам избежать применения вышеупомянутой линии кода в каждой странице.

Есть только одна общая проблема относительно буферизации Response — то, что пользователи чувствуют ASP-страницы менее «отзывчивыми» (даже при том, что время полного получения готовой страницы получается меньше) потому что они должны ждать полную страницу, которая будет произведена прежде, чем, они начинают видеть что-нибудь. Для длинных страниц, вы можете выключить буферизацию, установив Response.Buffer = False. Однако, лучшей стратегией будет использование метода Response.Flush. Этот метод показывает весь HTML, который был записан ASP в браузер. Например, после записи 100 строк из таблицы с 1000-ю записей, ASP может вызывать Response.Flush, чтобы вынудить показать браузер уже готовые 100 строк; это позволяет пользователю увидеть первые 100 строк таблицы прежде, чем остальные строки будут будут получены.

(Заметьте, что в вышеупомянутом примере таблицы с тысячью записей некоторые браузеры не будут отображать таблицу, пока они не получат заключительный HTML-тег

Exception Condition
ConfigurationErrorsException

. Так что проверьте ваш браузер на этот счет. Чтобы обойти эту проблему, попробуйте разделить таблицу на несколько более меньших таблиц (с меньшим количеством строк) и вызывать Response.Flush после каждой из них. Новые версии Internet Explorer отображают таблицы прежде, чем они полностью закончены и будут показывать их еще быстрее, если вы определите ширину столбцов таблицы — это поможет избежать расчетов, которые требуются браузеру для самостоятельного вычисления ширины столбцов путем измерения длины строк данных в каждой ячейке таблицы.

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

Совет 15: Группируйте однолинейный код и выражения Response.Write

Однолинейная конструкция VBScript записывает значение «выражения» в исходящий ASP-поток. Если буферизация response не включена (см. Совет 14), то при частом использовании таких выражений, каждое из них приведет к записи данных в браузер путем передачи по сети множества маленьких пакетов, что выполняется медленно. Точно также производительность приложения снижается при частом чередовании маленьких кусочков ASP-кода и HTML. Поэтому данный совет состоит в следующем: замените рядом стоящие однолинейные конструкции одним вызовом Response.Write. Например, в следующем примере отображения таблицы БД показано необоснованно частое переключение в каждой строке между однолинейным кодом VBScript и тэгами HTML:


Ниже приводится более эффективный код, содержащийся в едином блоке VBScript и призванный ускорить отображение данных:

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

Совет 16: Используйте Response.IsClientConnected перед получением больших объемов данных

Если пользователь нетерпелив и торопится, он может отказаться от вашей просмотра ASP-страницы прежде, чем вы начнете выполнять его запрос. Если он нажал в браузере Refresh или ушел на другую страницу вашего сервера, вы получите новый запрос, стоящий в конце очереди ASP-запросов и «отсоединенный» запрос, стоящий в середине очереди. Часто это случается когда ваш сервер сильно загружен (имеет длинную очередь запросов с, соответственно, большим временем ответа) и этот новый запрос делает ситуацию еще хуже. Нет никакого смысла выполнять ASP-скрипт (особенно медленный и тяжеловесный), если пользователь больше не соединен со своим запросом. Вы можете проверить это состояние, используя свойство Response.IsClientConnected. Если оно возвращает False вы должны вызвать Response.End и отказаться от получения остальной части страницы. Фактически, IIS 5.0 использует эту практику — всякий раз, когда ASP собирается выполнять новый запрос, он проверяет, чтобы увидеть как долго запрос был в очереди. Если он был там более, чем 3 секунд, ASP проверит, соединен ли все еще клиент и немедленно закончит запрос, если нет. Вы можете использовать AspQueueConnectionTestTime, чтобы установить этот таймаут в 3 секунды.

Если вы имеете страницу, которая требует очень много времени для выполнения, вы можете проверять Response.IsClientConnected на разных стадиях выполнения. Когда буферизация активирована — хорошая идея также вызывать Response.Flush, чтобы дать понять пользователю, что что-что работает.

Обратите внимание, что в IIS 4.0 Response.IsClientConnected не будет правильно работать, если вы сначала не делаете Response.Write. Если буферизация активирована вы будете также должны делать Response.Flush. На IIS 5.0 нет никакой потребности в этом — Response.IsClientConnected работает прекрасно. В любом случае Response.IsClientConnected требует некоторых затрат времени, поэтому используйте ее только перед действием, которое требует, скажем, по крайней мере, не менее 500 миллисекунд (это большой промежуток времени, если у вас большая нагрузка на сервер). Т.е. вы должны отдавать себе отчет в действиях и не вызывать Response.IsClientConnected перед выводом каждой строки таблицы БД, гораздо лучше будет, если такая проверка будет реже, возможно, перед выводом новых 20-ти или 50-ти строк.

Совет 17: Объявляйте объекты используя тег

Если вам нужно обращаться к объектам, которые затем могут быть не использованы в коде (особенно объекты, содержащиеся в объектах Server или Application), попробуйте объявлять их в global.asa используя следующий синтакс:

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

Совет 18: Используйте объявления TypeLib для ADO и других компонентов

При использовании ADO разработчики часто включают adovbs.txt чтобы получить доступ к различным константам ADO. Этот файл должен быть включен в каждую страницу, в которой нужно использовать эти константы. Но этот файл констант достаточно большой и увеличивает время трансляции каждой ASP-страницы и размер скрипта.

В IIS 5.0 введена способность связать с библиотекой типов компонента, которая позволяет вам один раз сослаться на библиотеку типов и использовать ее на каждой ASP-странице. Причем в каждой странице не надо будет компилировать файл констант и разработчикам компонентов не надо формировать файлы VBScript #include для использования в ASP.

Чтобы обращаться к ADO TypeLib разместите одно из следующих выражений в Global.asa:

Совет 19: Пользуйтесь преимуществами клиентской проверки правильности данных

Современные браузеры имеют широко развитую поддержку XML, DHTML, java-апплетов и Remote Data Service. Пользуйтесь преимуществами этих возможностей всякий раз, когда можете. Все эти технологии помогают сократить на запросах к серверу и обратно, выполняя клиентскую проверку правильности ввода данных (например, проверку, имеет ли кредитная карта правильную контрольную сумму и т.п.). Сократив на обращениях клиент-сервер, вы снимите дополнительную нагрузку с сервера, тем самым — сократите сетевой траффик (хотя начальная страница, посланная браузеру, скорее всего будет большей), а также снизите нагрузку с любых других конечных ресурсов, к которым обращается ваш север (базы данных и пр.). Кроме того, пользователю не надо будет ждать новую страницу с сообщением об ошибке и предложением вернуться назад. Однако все это не означает, что вам надо просто перенести всю вашу проверку с сервера на клиента, нет. Вы должны всегда делать проверку вводимых данных на сервере, потому что она поможет защитить против хакеров или браузеров, которые не поддерживают ваши клиентские процедуры проверки.

Много было сделано для создания HTML, «независимого от браузера». Это часто препятствует разработчику при извлечении выгоды от популярных особенностей браузеров, которые могли бы приносить пользу. Для высокопроизводительных веб-сайтов, которые беспокоятся о «досягаемости» для браузеров, хорошей стратегией будет оптимизация страниц под наиболее популярные программы просмотра. Особенности браузера могут быть легко обнаружены в ASP используя Browser Capabilities Component («компонент возможностей браузера»). Инструментальные средства типа Microsoft FrontPage могут помочь вам при проектировании кода, который будет работать с теми браузерами и версиями HTML, которые вы хотите.

Совет 20: Избегайте конкатенации строк в циклах

Множество программистов делают образование строк в циклах следующим образом:

В таком подходе есть несколько проблем. Во-первых, неоднократная конкатенация (соединение) строк берет квадратичное время или если сказать менее формально, то — время, которое потребуется на выполнение цикла, пропорционально квадрату количества записей к числу полей. Более простой пример сделает это более понятным.

На первом шаге цикла вы получаете одиносимвольную строку «A». Во второй раз VBScript должен перераспределить строку и скопировать два символа («AB») в s. На третьем шаге нужно перераспределить s снова и скопировать три символа в s. На шаге N (26), нужно перераспределить и скопировать N символов в s. Итого — общее количество 1+2+3+. +N, т.е. N*(N+1)/2 копирований.

Если предположить, что в первом примере было 100 записей и 5 полей, то внутренний цикл будут выполнен 100*5 = 500 раз и время, которое потребуется для копирования и перераспределения строк будет пропорционально 500*500 = 250000, что будет довольно много для копирования набора записей скромных размеров.

В этом примере код мог бы быть улучшен заменой конкатенации строк с Response.Write() или однолинейным скриптом ( ). Если буферизация response включена (как это должно быть), это будет быстро, как Response.Write только добавляет данные к концу буфера response. Никакое перераспределение не выполняется и это очень эффективно.

В отдельных случаях преобразования ADO-рекордсета в HTML-таблицу можно попробовать использование GetRows или GetString.

Если вы соединяете строки в JScript, то там строго рекомендуется использование оператора «+=»; т.е. используйте s += «строка», а не s = s + «строка».

Совет 21: Используйте кэширование страниц в браузере и proxy-сервере

По умолчанию в ASP отключено кэширование в веб-браузере и proxy. Смысл этого заключается в том, что ASP-страница — по своей природе динамическая и обычно содержит информацию, которая изменяется со временем. Если ваша страница содержит постоянные данные и не требует регенерации при каждом запросе, то вы должны включить кэширование для браузера и прокси. Это позволит браузерам использовать «кэшируемую» копию страницы в течение некоторого отрезка времени, которым вы можете управлять. Кэширование может значительно снизить нагрузку на вашем сервере.

Какие из динамических страниц могут быть кандидатами на кэширование? Вот некоторые примеры:

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

Заметьте, что с кэшированием в браузере или кэшированием proxy, вы получите меньшее количество хитов, зарегистрированных на вашем сервере. Поэтому, если вы хотите точно измерять количество просмотров страниц или количество показов баннеров, то скорее, всего вы не захотите воспользоваться кэшированием.

Кэширование в браузере управляется свойством «Expires» HTTP-запроса, который посылает веб-сервер браузеру. ASP обеспечивает два простых механизма, чтобы установить это свойство. Чтобы заставить страницу «устареть» через несколько минут — установите свойство Response.Expires. Следующий пример сообщает браузеру, что содержание данной страницы истекает через 10 минут:

Установка Response.Expires в отрицательное значение или 0 отключает кэширование. Использование большого отрицательного числа, например -1000 (немного больше, чем 1 день) будет лучше, в силу несоответствий между временем на сервере и в браузере. Второе свойство Response.ExpiresAbsolute позволяет вам устанавливать точное время, в течении которого содержание «устареет»:

Вместо использования объекта Response для того, чтобы установить истечение срока действия страницы, вы можете использовать HTML-тэг . Большинство браузеров «понимают» эту директиву, хотя proxy ее не используют.

Наконец, вы можете указывать является ли содержание допустимым для кэширования HTTP-proxy используя свойство Response.CacheControl. Установив это свойство в значение «Public» вы разрешите proxy кэшировать содержание страницы.

По умолчанию это свойство всегда установлено в «Private». Обратите внимание, что вы не должны разрешать кэширование для proxy страниц, которые показывают данные, специфичные для каждого пользователя, поскольку в этом случае proxy может показывать страницы пользователям с информацией других.

Совет 22: Используйте Server.Transfer вместо Response.Redirect

Метод Response.Redirect сообщает браузеру запросить другую страницу. Этот метод часто используется, чтобы переназначить запрос пользователя, например, к странице идентификации (login) или странице с сообщением об ошибке. Redirect вынуждает сделать новый запрос страницы, результат этого — то, что браузер должен сделать два запроса к веб-серверу и веб-сервер должен обработать дополнительный запрос. В новой версии IIS 5.0 введена новая функция Server.Transfer, которая передает выполнение другой ASP-странице на том же самом сервере. Это помогает избежать дополнительного запроса «браузер-сервер» и в общем и целом приводит к улучшению производительности системы, а также к более короткому времени редиректа и отображения страницы в браузере пользователя.

Следующий скрипт демонстрирует использование Server.Transfer для переназначения запроса в зависимости от значения переменной:

Server.Transfer посылает запрос из одного выполняемого ASP-файла к другому файлу. В течении редиректа выполнение первоначально запрошенного ASP-файла немедленно прекращается без очистки буфера вывода.

Совет 23: Используйте замыкающий слэш в URL каталогов

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

Проверьте, всегда ли вы используете замыкающий слэш (trailing slash) — наклонную черту вправо (/) в URL каталогов веб-сайта. Если опустить этот слэш браузер будет делать запрос к серверу, только для того, чтобы сообщить, что он спрашивает о каталоге. Затем браузер будет делать второй запрос, но уже со слэшем на конце URL, и только тогда веб-сервер будет возвращать «главный» (default) документ этого каталога или выдавать список файлов каталога, если в нем нет главного документа и разрешен просмотр каталога. Добавление к URL замыкающего слэша позволяет избежать первого бесполезного запроса к веб-серверу, что, естественно, экономит время, которое требуется для перехода по ссылке. Чтобы подобная ссылка выглядела более приятнее вы можете опустить слэш в названии URL.

Этот совет также относится и к записи ссылок на главную страницу веб-сайта. Используйте

Совет 24: Избегайте использования серверных переменных

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

Также пытайтесь избегать неопределенных вызовов объекта Request (например, Request(«Данные»)). Для элементов, находящихся не в Request.Cookies, Request.Form, Request.QueryString или Request.ClientCertificate, имеется неявный запрос к Request.ServerVariables. Запрос к коллекции Request.ServerVariablesе выполняется намного медленнее, чем доступ к другим коллекциям.

Совет 25: Сделайте upgrade системного программного обеспечения

Системные компоненты постоянно обновляются, поэтому рекомендуется, чтобы вы модернизировали (сделали upgrade) к самой последней версии. Лучше всего установить Windows 2000 (и следовательно, IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1 и JScript 5.1). IIS 5.0 и ADO 2.5 позволяют достичь значительного повышения производительности ваших приложений на мультипроцессорных системах. На серверах под управлением ОС Windows 2000 ASP может респределять нагрузку одновременно на четыре процессора и больше, принимая во внимание, что в предыдущей версии — под IIS 4.0, ASP не делал такого распределения и на два процессора. Насколько много вы используете скриптового кода и ADO в ASP-страницах вашего сайта, настолько больше повышения производительности вы должны увидеть после модернизации к Windows 2000.

Если вы не можете установить Windows 2000 сейчас, вы можете модернизировать ваше системное программное обеспечение к самым последним версиям SQL Server, ADO, VBScript и JScript, MSXML, Internet Explorer и пакета обновления NT 4 (Service Pack). Каждое из перечисленного позволяет улучшить выполнение работы и увеличить надежность.

Почему ASP.NET получает доступ к государственному серверу, даже если страница EnableSessionState = «False», но только для сайта VB.NET, а не для сайта С#?

Наш веб-сайт использует наше собственное настраиваемое управление сеансом отдельно от состояния сеанса ASP.NET. Но поскольку несколько специальных страниц используют службы отчетов SQL Server, нам также необходимо включить состояние сеанса ASP.NET. Поскольку мы находимся в среде с балансировкой нагрузки, мы включили ASP.NET State Server (aspnet_state.exe или «Out-of-Mode Mode» ) на отдельной серверной машине.

Сегодня я заметил, что когда мы временно сбили машину с государственной службой в нашей среде Dev, сайт Dev перестал работать ( «Не удалось сделать запрос состояния сеанса на сервер состояния сеанса» ). Это несмотря на наличие EnableSessionState = «False» на загружаемой странице.

Почему ASP.NET должен подключиться к государственной службе при обслуживании запроса на страницу, которая не использует состояние сеанса? Это происходит, даже если страница не использует главную страницу, базовую страницу или любые пользовательские элементы управления. Я просмотрел весь наш код, чтобы гарантировать, что мы никогда не будем программно повторно включать состояние сеанса или пытаться получить к нему доступ.


— ИЗМЕНИТЬ ПОСЛЕ БОЛЬШЕ УСТРАНЕНИЯ НЕИСПРАВНОСТЕЙ —

Как было предложено ниже, я попытался создать веб-сайт с нуля, чтобы протестировать его без каких-либо осложнений от httpHandlers, httpModules или другой пользовательской логики.

ENABLESESSIONSTATE and Global.asa

I have an asp page in which first line is

I want to stop the sessions for this page. I have global.asa page whose code
is like this

When IIS is restarted and hit my asp page it goes to global.asa
session_onStart though I have disabled sessions on my page.

I dont want to execute global.asa at all when session is disabled on the
page. I get this wrong behavior only when IIS is restarted and page is hit
for the first time. for successive hits it doesnt go to global.asa and
keeps the session disable on the page.

I have tested for this 2 scenarios and I get the satisfactory results as per
my desire

1. u create a web application in IIS and disable session (by unchecking
«Enable Session State») , the page does not go to global.asa
2. if you dont create a web application and keep just a folder or a virtual
directory then the page does not go to global.asa

any clues why it goes to global.asa in other cases.

My first line in my asp page is as below

[in earlier post I had typed it wrong but my code has correct line as above.
Still my issue is the same as per previous post]

I have an asp page in which first line is

I want to stop the sessions for this page. I have global.asa page whose
code is like this

When IIS is restarted and hit my asp page it goes to global.asa
session_onStart though I have disabled sessions on my page.

I dont want to execute global.asa at all when session is disabled on the
page. I get this wrong behavior only when IIS is restarted and page is
hit for the first time. for successive hits it doesnt go to global.asa
and keeps the session disable on the page.

I have tested for this 2 scenarios and I get the satisfactory results as
per my desire

1. u create a web application in IIS and disable session (by unchecking
«Enable Session State») , the page does not go to global.asa
2. if you dont create a web application and keep just a folder or a
virtual directory then the page does not go to global.asa

any clues why it goes to global.asa in other cases.

I have an asp page in which first line is

I want to stop the sessions for this page. I have global.asa page whose
code is like this

To avoid hitting global.asa you should disable the session using the IIS
management console.

When IIS is restarted and hit my asp page it goes to global.asa
session_onStart though I have disabled sessions on my page.

I dont want to execute global.asa at all when session is disabled on the
page. I get this wrong behavior only when IIS is restarted and page is
hit for the first time. for successive hits it doesnt go to global.asa
and keeps the session disable on the page.

I have tested for this 2 scenarios and I get the satisfactory results as
per my desire

1. u create a web application in IIS and disable session (by unchecking
«Enable Session State») , the page does not go to global.asa
2. if you dont create a web application and keep just a folder or a
virtual directory then the page does not go to global.asa

any clues why it goes to global.asa in other cases.

Theortically it says that when a page includes EnableSessionState = false it
stops the session though Session is enabled in IIS management
console. then why this is not happening for that page after IIS
restart.

thanks
«Egbert Nierop (MVP for IIS)» wrote in
message news:ug**************@TK2MSFTNGP10.phx.gbl.

I have an asp page in which first line is

I want to stop the sessions for this page. I have global.asa page whose
code is like this

To avoid hitting global.asa you should disable the session using the IIS
management console.

When IIS is restarted and hit my asp page it goes to global.asa
session_onStart though I have disabled sessions on my page.

I dont want to execute global.asa at all when session is disabled on the
page. I get this wrong behavior only when IIS is restarted and page is
hit for the first time. for successive hits it doesnt go to global.asa
and keeps the session disable on the page.

I have tested for this 2 scenarios and I get the satisfactory results as
per my desire

1. u create a web application in IIS and disable session (by unchecking
«Enable Session State») , the page does not go to global.asa
2. if you dont create a web application and keep just a folder or a
virtual directory then the page does not go to global.asa

any clues why it goes to global.asa in other cases.

Theortically it says that when a page includes EnableSessionState = false
it stops the session though Session is enabled in IIS management
console. then why this is not happening for that page after IIS
restart.

This is by design because global.asa cannot know that **all** or just a
**few** pages have the sessionstate turned of.
the ASP framework, therefore, always creates a session cookie. After that,
it is not reused in your case.

Only by disabling it by the IIS it is disabled for global.asa as well.
And the enablesessionstate = false does not work for global.asa (might not
be documented. ).

thanks
«Egbert Nierop (MVP for IIS)» wrote in
message news:ug**************@TK2MSFTNGP10.phx.gbl.

I have an asp page in which first line is

Состояние сеанса может использоваться только в том случае, если для свойства enableSessionState установлено значение true, либо в конфигурации

Я работаю над приложением Asp.net MVC 2 с c #, используя vs 2010. У меня ниже упомянутая ошибка, когда я запускаю свое приложение локально в режиме отладки.

Изображение сообщения об ошибке, как показано ниже:

Текст сообщения об ошибке, как показано ниже:

Состояние сеанса можно использовать только в том случае, если для свойства enableSessionState установлено значение true, либо в файле конфигурации, либо в директиве Page. Пожалуйста также убедитесь, что System.Web.SessionStateModule или пользовательское состояние сеанса модуль включен в \ \ раздел в конфигурации приложения.

Что я сделал для решения этой проблемы, как показано ниже:

Попробуйте 1: файл web.config был изменен, как показано ниже:

Попробуйте 2, как показано ниже:

Но, к сожалению, у меня все еще есть проблема, о которой я упоминал выше.

Есть ли у вас решение для этого?


12 ответов

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

Вы также включили состояние сеанса в разделе?

Или вы добавили это на страницу?

И вы убедились, что ASP.NET Session State Manager Service служба работает? На вашем скриншоте это не так. Он установлен в режим запуска Manual который требует от вас запускать его каждый раз, когда вы хотите его использовать. Чтобы запустить его, выделите сервис и нажмите зеленую кнопку воспроизведения на панели инструментов. Чтобы запустить его автоматически, отредактируйте свойства и настройте тип запуска.

Или установите свойство режима SessionState на InProc , так что государственная служба не требуется.

Примечание. Лучше, чтобы ваш контроллер получал значение из сеанса и добавлял значение в модель для вашей страницы/элемента управления (или в ViewBag), чтобы представление не зависело от HttpSession, и вы можете выбрать другой источник для этого элемента позже с минимальными изменениями кода. Или даже лучше, не использовать состояние сеанса вообще. Это может снизить производительность, если вы используете много асинхронных вызовов JavaScript.

также, если вы работаете с SharePoint и сталкиваетесь с этой ошибкой, не забудьте запустить

или вы продолжите получать вышеуказанное сообщение об ошибке.

Я хочу, чтобы все знали, что иногда эта ошибка просто является результатом какой-то странной ошибки памяти. Перезагрузите компьютер и вернитесь в visual studio, и он исчезнет! Bizarre! Попробуйте, прежде чем начать играть с вашим файлом веб-конфигурации и т.д., как я сделал . ;-)

На самом деле jessehouwing дал решение для нормального сценария.

Но в моем случае я включил 2 типа сеансов в моем web.config file

Так что в моем случае я должен прокомментировать Второй. Это то, что нужно для производства. Когда я закомментировал второй, моя проблема исчезла.

В моем случае проблема ушла просто с помощью HttpContext.Current.Session вместо Session

Я понимаю, что есть принятый ответ, но это может помочь людям. Я обнаружил, что у меня была похожая проблема с сайтом ASP.NET, использующим инфраструктуру NET 3.5, при запуске его в Visual Studio 2012 с использованием IIS Express 8. Я попробовал все вышеперечисленные решения, но ни одно из них не сработало — в конце концов, запустив решение в встроенный веб-сервер VS 2012 работал. Не уверен почему, но я подозреваю, что это была связь между 3.5 framework и IIS 8.

Для SharePoint Можно найти файл веб-конфигурации в C: \ inetpub \ wwwroot \ wss \ VirtualDirectories \ Sitecollection номер порта — и внести изменения

и с помощью командной консоли SharePoint запустите команду ниже

Я нашел решение, которое работало отлично! Добавьте следующее в web.config:

Надеюсь, это поможет кому-то еще!

Я получил эту ошибку только при отладке приложения ASP .Net.

У меня тоже было Session[«mysession»] переменные добавлены в мои часы Visual Studio.

проблема была решена однажды, я удалил переменные сеанса из наблюдения.

Эта ошибка возникла для меня из-за необработанного исключения, брошенного в Public Sub New() (Visual Basic) конструктор функции веб-страницы в коде позади.

Если вы реализуете функцию конструктора, оберните код в оператор Try/Catch и посмотрите, решит ли он проблему.

Состояние сеанса может быть нарушено, если у вас есть следующее в Web.Config:

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

Изучение сессии в 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 при Postback’е[Решено]

Столкнулся с оригинальной фичей IIS’а при программировании на ASP.NET. Есть форма, на ней кнопка — при первоначальном формировании страницы в Page_Load, — могу записывать данные в HttpContext.Current.Session. А вот при постбеке, в методе обработки нажатия кнопки — эта самая HttpContext.Current.Session возвращает null. Уже весь гугл перерыл и ничего не добился. это я тупой или просто лыжи не едут?

А что такое постбэк?

=A=L=X=
> А что такое постбэк?

А это тоже, оригинальнаяый фича геморрой от Microsoft, — когда для обработки нажатия на кнопку, — содержимое формы отправляется обратно на сервер, томуже самому скрипту, который страницу сформировал.

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

что то вы путаете. посмотрите настройки вёб конфига. может у вас сессия отключена. Всё работает.
Вот мой шорт тест.

вёб конфиг дефолтный. со включенным дебагом. руками ничего не менял.

ЗЫ. да. имя кнопки таки станет «test» после нажатия на неё.

update: тег code

ztranger
> что то вы путаете. посмотрите настройки вёб конфига. может у вас сессия
> отключена. Всё работает.

Кроме того, вызывать HttpContext.Current.Session — оказывается не правильно, нужно пользоваться Page.Session. только эффекты не менее интересные

Все осложнено тем, что на серваке стоит WSS 3.0. И да действительно, если страничка хранится в файловой системе, и я её вызываю через _layouts/blablalbla/test.aspx замечательно все работает, и при первом формировании страницы и при постбэках. Стоит положить эту страничку в библиотеку документов, — начинаются чудеса.

А если я вставляю enableSessionState=»true» в , то оно заявляет, что sessionState запрещены на данной странице.

то есть вы создаёте не страницу а вёб контрол ?
>>Стоит положить эту страничку в библиотеку документов
или я не так понял?

ztranger
> то есть вы создаёте не страницу а вёб контрол ?
> > > оит положить эту страничку в библиотеку документов
> или я не так понял?

Нет, именно веб страницу, разметка в библиотеке документов, а обработчики в DLL, размещенной в GAC’е.

Всем спасибо за внимание, — проблема решена (M$ как всегда на «высоте» со своими заморочками)

Нужно найти в web.config секцию

и изменить её следующим образом

либо для каждого отдельного aspx

Дополнительный бонус, — после этого можно код обработчиков оставлять в aspx, а не извращаться с DLLкой в GAC’е

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