Losing Session State
I have an ASP.net application where Users aren't able to successfully complete certain actions, for reasons, I'm assuming, can only be related to losing their session (which is where I maintain their current user information, and how determine whether they are logged in)
I'm at a loss as to why they would lose their session, so my first question is:
What (in general) would cause a user to lose their session in ASP.net?
and since I don't know when a user loses their session and can't reproduce it myself:
How can I track when I user loses their session
Below is my sessionState config for reference
<sessionState
mode="InProc"
cookieless="false"
cookieName="My.Site.Com"
timeout="480"/>
2 ответа
Ряд вещей может вызвать загадочное исчезновение состояния сеанса.
- Истекло время ожидания вашего sessionState
- Вы обновляете свой web.config или другой тип файла, из-за чего ваш AppDomain перезагружается
- Ваш AppPool в IIS перезагружает
- Вы обновляете свой сайт, добавляя много файлов, и ASP .NET заранее уничтожает ваш AppDomain, чтобы перекомпилировать и сохранить память.
-
Если вы используете IIS 7 или 7.5, вот несколько вещей, на которые следует обратить внимание:
- По умолчанию IIS настраивает пулы приложений таким образом, чтобы они автоматически отключались после определенного периода бездействия.
- По умолчанию IIS настраивает AppPools на повторное использование каждые 1740 минут (очевидно, в зависимости от вашей корневой конфигурации, но это значение по умолчанию)
- В IIS проверьте «Расширенные настройки» вашего AppPool. В нем есть свойство, называемое «Тайм-аут простоя». Установите его на ноль или на большее число, чем значение по умолчанию (20).
- В IIS проверьте настройки «Утилизация» вашего AppPool. Здесь вы можете включить или отключить утилиту AppPool. Вторая страница мастера - это способ регистрации в журнале событий каждого типа завершения работы AppPool.
Если вы используете IIS 6, применяются те же настройки (по большей части, но с разными способами доступа к ним), однако заставить их регистрировать повторные циклы гораздо сложнее. Вот ссылка на способ заставить IIS 6 регистрировать события повторного цикла AppPool:
-
Если вы обновляете файлы в своем веб-приложении, вы должны ожидать, что весь сеанс будет потерян. Такова природа зверя. Однако вряд ли можно ожидать, что это произойдет несколько раз.Если вы обновите 15 или более файлов (aspx, dll и т. Д.), Существует вероятность того, что у вас будет несколько перезапусков в течение определенного периода времени, поскольку эти страницы перекомпилируются пользователями, обращающимися к сайту. См. Эти две ссылки:
http://support.microsoft.com/kb/319947
Установка большего числа numCompilesBeforeAppRestart (или ручное переключение пула приложений) устранит эту проблему.
-
Вы всегда можете обработать Application_SessionStart и Application_SessionEnd, чтобы получать уведомления о создании или завершении сеанса. Класс HttpSessionState также имеет свойство IsNewSession , которое вы можете проверить в любом запросе страницы, чтобы определить, создается ли новый сеанс для активного пользователя.
-
Наконец, если это возможно в ваших обстоятельствах, я успешно использовал режим сеанса SQL Server . Не рекомендуется, если вы храните в нем большой объем данных (каждый запрос загружает и сохраняет полный объем данных с SQL Server), и это может быть проблемой, если вы помещаете в него настраиваемые объекты (поскольку они должны быть сериализуемыми. ), но это помогло мне в сценарии общего хостинга, когда я не мог настроить свой пул приложений так, чтобы он не перерабатывал пару часов. В моем случае я хранил ограниченную информацию, и это не оказало отрицательного воздействия на производительность. Добавьте к этому тот факт, что существующий пользователь будет повторно использовать свой SessionID по умолчанию, и мои пользователи никогда не замечали того факта, что их сеанс в памяти был отброшен повторным циклом AppPool, потому что все их состояние было сохранено в SQL Server.
Вы можете добавить некоторые логи в Global.asax в Session_Start и Application_Start, чтобы отслеживать, что происходит с сессией пользователя и приложением в целом.
Кроме того, обратите внимание, если вы работаете в режиме Web Farm (несколько потоков IIS, определенных в пуле приложений) или балансировки нагрузки, потому что пользователь может попасть на другой сервер, который не имеет такой же памяти. В этом случае вы можете переключить режим сеанса на SQL Server.