Я анализирую проблему производительности на сайте WSS 3.0 со сбалансированной нагрузкой.
На сайте используется циклическая балансировка нагрузки и аутентификация Windows с NTLM.
Одна из проблем заключается в чрезмерном количестве ответов http 401.2. Есть периоды, когда есть пять ответов 401.2, за которыми следует один 401.1, за которым следует один 200. Это рукопожатие выполняется для каждого запрошенного файла.
Мне интересно, вызывает ли циклический алгоритм дополнительные 401,2 ответа.
Мне неясно, говорите ли вы о циклической балансировке нагрузки DNS или если вы используете балансировщик нагрузки уровня 7, который выполняет циклическую балансировку нагрузки сеансов HTTP. Также неясно, разрешаете ли вы клиентам использовать постоянные соединения HTTP / 1.1 с серверами приложений.
Короче говоря, балансировка нагрузки DNS не должна вызывать наблюдаемого вами поведения. Балансировка нагрузки на уровне 7 наверняка может, особенно если вы не позволяете клиентам поддерживать постоянные соединения открытыми с серверами приложений.
Некоторое количество ответов 401 на запросы клиентов в среде NTLM-over-HTTP является нормальным. Рукопожатие NTLM-over-HTTP выглядит так:
Вы можете получить более подробную информацию на http://www.innovation.ch/personal/ronald/ntlm.html (включая побайтовые описания заголовков и т. д.).
Проверка подлинности NTLM-over-HTTP позволяет аутентифицировать каждое соединение, поэтому требуются сообщения keepalive соединения или постоянные сеансы HTTP / 1.1. Если, гипотетически, вы не используете постоянные соединения и случайным образом пересылаете клиентские запросы и ответы на запросы NTLM между разными серверами IIS, тогда у вас возникнут проблемы (и, честно говоря, я даже представить себе не могу, что это сработает).
Возможно, это связано с тем, что аутентификация плохая для каждого запроса, если вам нужно соединение с отслеживанием состояния. Я видел похожие вещи, когда балансировщик нагрузки был настроен на использование циклического перебора. Происходит то, что ViewState в WSS аутентифицируется для сервера, а состояние просмотра зашифровывается с помощью машинного ключа. Если эти ключи синхронизируются не на всех серверах в группе состояние просмотра будет плохим и вызовет повторную аутентификацию ... это будет происходить до тех пор, пока не произойдет 2 или 3 запроса к одному и тому же серверу. Первый запрос не авторизован (запрос 1), мы знаем это, потому что это новый пользователь, поэтому следующий запрос отправляет аутентификацию (запрос 2), а следующий отправляет запрос, который был отправлен по запросу 1, но с хорошим состоянием просмотра (запрос 3). Если в любой момент в этой цепочке запросов вы отправлены на другой сервер, она начнется заново.
Проверьте системный журнал, есть ли у вас куча ошибок asp.net из-за плохого состояния просмотра? Странные ошибки шифрования? Я не знаю, улавливает ли WSS их до того, как они попадают в этот журнал, или нет, во многих приложениях .net он не улавливается и его можно увидеть в средстве просмотра событий.
Чтобы исправить это, синхронизируйте ключи или используйте липкий.