Состояние сеанса и сборка мусора в IIS6 для Classic ASP

Question

Это вопрос о возврате, и, вероятно, относительно фундаментальный, но я в растерянности.

Как IIS управляет состоянием сеанса Classic ASP?

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

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

Если это правильно, есть ли способ контролировать это с помощью существующего кода приложения?

Спасибо!

Answer 1

Сеансы ASP хранятся в виде простых объектов COM в памяти, когда процесс, в котором размещено приложение ASP, завершается, так же как и все сеансы.

ASP не "перерабатывает" активные сеансы. Однако существует ряд других обстоятельств, которые могут повлиять на сеансы ASP.

Тайм-аут простоя пула приложений

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

В диспетчере IIS откройте свойства пула, в котором работает ваше приложение ASP. Взгляните на вкладку «Производительность». Время простоя по умолчанию составляет 20 минут. Следовательно, если вы указали тайм-аут сеанса, скажем, 60 минут, и вы «тестируете» этот тайм-аут, вы фактически обнаружите, что тайм-аут сеанса истек через 20 минут. Отсутствие активности убило пул приложений.

Переработка пула приложений

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

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

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

Веб-сад

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

Session.Abandon или Session.Clear

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

Answer 2

Эта проблема для меня оказалась количеством рабочих процессов на вкладке Производительность. Он был установлен в 2 по какой-то причине. Мы установили его обратно в 1, и проблема исчезла.

Answer 3

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

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

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

Реализация объектного кэширования в классическом ASP с утечкой памяти