asp.net, сервер состояний, NLB, сеанс потерян

Question

1-й пост на stackoverflow, надеюсь, что вы получите отличную обратную связь

В настоящее время я пытаюсь сбалансировать загрузку нашего веб-сайта. Мы настроили 2 кластера NLB на Windows Server 2003 с IIS 6.

Во время тестирования установки я обнаружил, что иногда наша сессия теряется. Через полтора дня вот результат:

1. Да, наш machine.config имеет одинаковый ключ шифрования / дешифрования.
2. Да, идентификатор в iis metabase.xml одинаков для обеих машин. На самом деле, весь файл одинаков, за исключением «AdminACL».
3. Для обоих веб-приложений установлен StateServer, и оба они указывают на один и тот же компьютер.

С этого момента поиск в Google дает меньше информации и возможных решений.

Из того, что я знаю, нет конкретного паттерна, вызывающего эту проблему. Это случается время от времени.

При попытке найти проблему я видел, что запрос отправил на сервер файл cookie идентификатора сессии asp, но сервер не сопоставил его с сеансом пользователя.

Итак, запрос номер x был отправлен от клиента, с cookie, сеанс был сопоставлен, и все прошло гладко. Номер запроса x + 1 был отправлен от клиента с файлом cookie, но сеанс не найден.

Оба запроса были сделаны на одной машине в NLB.

Вот фрагмент asp trace.axd:

1-й запрос:

Запрос деталей Идентификатор сеанса: j2ffvy45updpc52uhw1mbg55 Тип запроса: GET Время запроса: 26.11.2008 14:58:06 Код состояния: 200 Кодировка запроса: Unicode (UTF-8) Кодировка ответа: Unicode (UTF-8)

Запрос коллекции куки

Имя Значение Размер

ASP.NET_SessionId j2ffvy45updpc52uhw1mbg55 42 ПОМОЩЬ 22 9

Коллекция ответных файлов cookie

Имя Значение Размер

Коллекция заголовков

Имя Значение

Cookie ASP.NET_SessionId = j2ffvy45updpc52uhw1mbg55; AID = 22 * ​​1045 *

2-й запрос:

Подробности запроса Идентификатор сеанса: Тип запроса: POST Время запроса: 26.11.2008 14:58:08 Код статуса:
Кодировка запроса: Unicode (UTF-8) Кодировка ответа:

Запрос коллекции файлов cookie

Имя Значение Размер

Коллекция ответных файлов cookie

Имя Значение Размер

Коллекция заголовков Имя Значение Cookie ASP.NET_SessionId = j2ffvy45updpc52uhw1mbg55; AID = 22 * ​​1060 *

Как вы можете видеть во втором запросе, cookie отправляется клиентом, но asp, похоже, никогда не добавляет cookie в свою «Коллекцию запросов Cookies». Я думаю, именно поэтому он не находит сессию.

Так почему же cookie не отображается в сеансе? Это проблема? Проблема в другом месте?

Не стесняйтесь спрашивать любые разъяснения.

Спасибо всем за отзыв.

JF

Answer 1

Я наконец нашел ответ на свою проблему. Его происхождение находится в коде приложения (например, 99% ошибок программистов сторонних разработчиков). Я решил опубликовать его в любом случае, если кто-то находится в подобном сценарии.

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

Важной частью является следующее: Класс WebServiceRequester содержит объекты WebService. Объекты WebService нельзя сохранить в сеансе, они не сериализуются в asp. Свойство имеет атрибут [NonSerialized]. Поэтому каждый раз, когда мы обращались к свойству «WebService» объекта для первого в течение жизненного цикла страницы, нам приходилось создавать новое и присваивать ему URL «m_webServiceURL», который был сохранен в сеансе. Итак, вы видите, что новый объект веб-сервиса, возможно, на другом компьютере, означает разные настройки на каждом компьютере.

вот что случилось: поле 29 было настроено для доступа к веб-службе на локальном хосте

поле 30 было установлено для доступа к веб-службе как 192.168.253.29.

Технически, они оба установлены на одной машине. Но вот сценарий:

вход в систему в окне 29. Для m_webServiceURL в сеансе задано значение localhost.

[какой-то запрос по вставке 29 здесь]

Балансировка NLB приводит нас к коробке 30. поле 30 загружает его сеанс, создайте новый объект веб-службы с localhost в качестве адреса веб-службы. Блок 30 сделал запрос к неправильному веб-сервису, что привело к исключению Session Expired.

Одной из проблем во время отладки было то, что локальная связь не была записана сетевым монитором.

Что привело меня на трассировку, так это то, что мы никогда не регистрировали исключение на трассировке журнала 29, как и должно быть.

Спасибо за ваши предложения всем, это было действительно оценено.

Хорошего дня. JF

Answer 2

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

Answer 3

Попробуйте установить доменное имя asp.net_sessionid через код ".yourdomain.com". По умолчанию доменное имя файла cookie ASP.net_SessionID имеет полный путь к приложению. Таким образом, это может быть одной из причин, по которой куки не перемещаются.

например. Request.Cookies ["ASP.NET_SessionId"]. Domain = ".yourdomain.com". Помните первое "." важно в доменном имени.

Вы можете сделать это в HttpModule в событии AcquireRequestState.

Answer 4

Несколько моментов, которые следует учитывать:

• Какая нагрузка на ваш сайт? State Server имеет тенденцию падать, когда сталкивается с большим количеством одновременных попаданий. Мы используем его только в тех случаях, когда у нас очень небольшое количество пользователей (в 10-х, в основном, бэкэнд-систем). Всякий раз, когда мы пытались использовать его в работе для сайтов, обслуживающих тысячи пользователей ежедневно, это приводило к сбою, приводящему к потере данных сеанса.
• В одной из управляемых нами производственных сред мы используем MSSQL 2005 Express для управления сеансами, на сайте более 10 000 пользователей в день и 200 000 страниц в день. Это рекомендуемый подход, если сессия обязательна и тесно связана с вашим приложением.

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

Удачи

Answer 5

Я буду хромать и повторю предложение MS SQL Server. Установите SQL Server Express, который полностью бесплатен, в том числе для коммерческого использования, и имеет только три недостатка, которые не должны быть проблемой для вас на этом этапе:

• Макс. Размер базы данных 4 ГБ
• Макс. 1 ядро ​​процессора используется
• Макс. 1 ГБ ОЗУ использовано

Answer 6

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

Возможно, эта статья по устранению неполадок в сеансе поможет?

Или " Устранение неполадок, связанных с сеансом, в ASP.NET "

Или « Устранение неполадок с истекшим состоянием сеанса ASP.NET и ваши параметры »

Answer 7

Ну, если вы используете Visual Studio, вы можете по крайней мере протестировать его с MSDE (урезанная версия SQL Server, поставляемая с Visual Studio) ...

Это может помочь исключить проблемы с сервером состояний ...

Answer 8

Не совсем ответ на ваш вопрос, но пробовали ли вы использовать хранилище сеансов на основе сервера sql? (Ищите в MSDN постоянный скрипт, а не временный скрипт, предоставляемый с asp.net)

Я слышал "плохие вещи" о исполняемом сервисе сеанса и, следовательно, не использовал его. Никогда не было проблем с веб-фермерством с помощью решения на основе сервера sql.

Извините, это не совсем ответ на вашу проблему, но он должен либо (а) исправить, либо (б) значительно сузить ее.