случайное время ожидания сеанса IIS

Question

У меня очень странная проблема, и я ищу любой совет. У меня есть веб-сайт ASP.NET, работающий под управлением IIS 6, который по большей части работает хорошо. Тем не менее, сеансы кажутся случайно очищенными? Так что, если я войду в систему ... кликни вокруг, я получаю загрузку случайно. Иногда это после 30 секунд / 4 клика. Иногда это первый клик, иногда он даже не позволяет войти в систему ... а иногда работает нормально ?? (причина, по которой я знаю, что она очищается, потому что я печатаю сеанс, когда я выхожу из системы, а они пусты)

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

Кроме того, есть ли какие-нибудь советы о том, как я могу узнать больше о том, что происходит на сессиях?

Самая странная часть моей проблемы - это случайность. Который, вероятно, послужит хорошей подсказкой для причины для эксперта IIS / ASP.NET. (по крайней мере, я на это надеюсь!)

Еще одна подсказка: сайт прекрасно работает, когда я размещаю его локально, и проблема возникает только тогда, когда я размещаю его на своем виртуальном годичном сервере. (под управлением IIS 6)

еще одна вещь, которую я заметил

на локальном хосте мои куки выглядят так: (от firebug) Cookie ASP.NET_SessionId = vgt4ly45frvsm1qsfjsmdcbc; имя пользователя =; демо = истина

на размещенном сервере это просто так: Cookie ASP.NET_SessionId = vgt4ly45frvsm1qsfjsmdcbc;

"username" - это имя моего сеанса ... может быть, у меня отключены файлы cookie на общем хостинге, и это приводит к тому, что сеанс не работает?

Спасибо за ваше время, Andrew

Answer 1

Ваше приложение asp.net может быть переработано. Переработка может произойти, если будет достигнут порог памяти или процессора, или через некоторое время (15-минутное бездействие использовалось по умолчанию в IIS6).

При утилизации приложения все в памяти теряется. Возможно, именно поэтому вы теряете данные сеанса.

Чтобы убедиться, что переработка является причиной, вы можете посмотреть счетчик производительности на своем сервере или просто записать что-нибудь в обработчик Application_Start global.asax.

Чтобы просмотреть список счетчиков производительности asp.net на IIS6, установите флажок https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/0a6c9f07-a70c-4c3d-b93d-5dfef593c744.mspx?mfr=true

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

Answer 2

чтобы ответить на мой вопрос:

эта ссылка была очень полезной:

http://msdn.microsoft.com/en-us/library/ms972429.aspx

а именно эта часть:

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

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

Андрей

Answer 3

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

Вот статья MSDN об этом.