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

https://stackoverflow.com/questions/322277

11-07-2019
|

Вопрос

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

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

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

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

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

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

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

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

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

Вот фрагмент трассировки asp.axd:

1- й запрос:

Запрашивать подробности Идентификатор сеанса:тип запроса j2ffvy45updpc52uhw1mbg55:ПОЛУЧИТЬ Время запроса:26.11.2008 2:58:06 Код состояния:200 Кодирование запроса:Кодировка ответа в Юникоде (UTF-8):Юникод (UTF-8)

Запросить сбор файлов cookie

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

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

Сбор файлов cookie-ответов

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

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

Значение имени

Файл cookie ASP.NET_SessionId=j2ffvy45updpc52uhw1mbg55;ПОМОЩЬ=22

2-й Запрос:

Запрашивать подробности Идентификатор сеанса:Тип запроса:Публикация Время запроса:26.11.2008 2:58:08 Код состояния:
Кодирование запроса:Кодировка ответа в Юникоде (UTF-8):

Запросить сбор файлов cookie

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

Сбор файлов cookie-ответов

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

Коллекция заголовков Значение имени Файл cookie ASP.NET_SessionId=j2ffvy45updpc52uhw1mbg55;ПОМОЩЬ=22

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

Итак, почему файл cookie не привязан к сеансу?В этом ли проблема?Проблема в чем-то другом?

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

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

Решение

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

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

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

итак, вот что произошло:поле 29 было настроено на доступ к веб-службе на localhost

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

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

войдите в систему в поле 29.m_webServiceURL имеет значение localhost в сеансе.

[некоторые запросы во вставке 29 здесь]

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

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

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

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

Хорошего вам дня.JF

Другие советы

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

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

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

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

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

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

Возможно эта статья об устранении неполадок сеанса помогло бы?

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

Или "Срок устранения неполадок истек ASP.NET Состояние сеанса и ваши параметры"

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

Максимальный размер базы данных 4 ГБ
Максимум 1 используемое ядро процессора
Максимальное количество используемой оперативной памяти 1 ГБ

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

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

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

Удачи

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

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

Например.Запрос.Файлы cookie["ASP.NET_SessionId"].Домен = ".yourdomain.com".Помните, что первое "." важно в доменном имени.

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow