Как Round Robin verus Sticky IP влияет на производительность

Я анализирую проблему производительности на сайте Load Balanced WSS 3.0.

На сайте используется балансировка нагрузки Round Robin и проверка подлинности Windows с NTLM.

Одной из проблем является чрезмерное количество ответов http 401.2. Существуют периоды, когда за пятью ответами 401.2 следует один ответ 401.1, за которым следует один 200. Это рукопожатие выполняется для каждого запрошенного файла.

Я задаюсь вопросом, вызывает ли циклический перебор лишние ответы 401.2.

2 ответа

Решение

Возможно, это связано с тем, что аутентификация плоха при каждом запросе, если вам нужно соединение с состоянием. Я видел похожие вещи, когда балансировщик нагрузки настроен на использование циклического перебора. Что происходит, так это то, что ViewState на WSS аутентифицируется для сервера, а ViewState шифруется с использованием ключа машины. Если эти ключи не синхронизируются на всех серверах в группе, состояние просмотра будет плохим, и произойдет принудительная повторная аутентификация... это будет происходить до тех пор, пока не произойдет 2 или 3 запроса на один и тот же сервер. Первый запрос не авторизован (запрос 1), мы знаем это, потому что это новый пользователь, поэтому следующий запрос отправляет авторизацию (запрос 2), а следующий отправляет запрос, который был отправлен по запросу 1, но с хорошим состоянием просмотра (запрос 3). Если в любой момент в этой цепочке запросов вы отправляетесь на другой сервер, он начинается заново.

Проверьте системный журнал, есть ли у вас куча ошибок asp.net для плохого состояния просмотра? Странные ошибки шифрования? Я не знаю, перехватывает ли WSS, прежде чем они попадут в этот журнал или нет, во многих приложениях.net он не перехватывается и его можно увидеть в средстве просмотра событий.

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

Мне неясно, говорите ли вы о циклическом распределении нагрузки DNS или используете балансировщик нагрузки уровня 7, который выполняет циклическое распределение нагрузки сеансов HTTP. Также неясно, разрешаете ли вы клиентам использовать постоянные соединения HTTP/1.1 с серверами приложений.

Короче говоря, балансировка нагрузки DNS не должна вызывать поведение, которое вы видите. Балансировка нагрузки на уровне 7, безусловно, может, особенно если вы не разрешаете клиентам сохранять постоянные соединения открытыми для серверов приложений.

Некоторое количество 401 ответов на клиентские запросы в среде NTLM-over-HTTP является нормальным. Рукопожатие NTLM-over-HTTP таково:

  • клиент делает запрос
  • сервер отвечает с помощью "401.2 Unauthorized" и "WWW-Authenticate: NTLM" заголовка ответа
  • клиент отвечает другим запросом с заголовком "Authorization: NTLM" и первоначальным ответом аутентификации NTLM
  • сервер отвечает с помощью "401.1 Unauthorized" и "WWW-Authenticate: NTLM" заголовка ответа, который содержит запрос NTLM
  • клиент отвечает другим запросом с заголовком "Authorization: NTLM" и ответом NTLM
  • сервер выполняет запрос клиента (т.е. они аутентифицированы)

Вы можете получить более подробную информацию по адресу http://www.innovation.ch/personal/ronald/ntlm.html (включая побайтные описания заголовков и т. Д.).

Проверка подлинности NTLM-over-HTTP проверяет подлинность каждого соединения, поэтому требуются сообщения поддержки активности или постоянные сеансы HTTP/1.1. Если, гипотетически, вы не используете постоянные соединения и произвольно перенаправляющие клиентские запросы и ответы на вызовы NTLM между различными серверами IIS, то у вас возникнут проблемы (и, честно говоря, я не могу представить, что это будет работать).

Другие вопросы по тегам