0

I am analysing a performance problem on a Load Balanced WSS 3.0 site.

The site uses Round Robin load balancing and Windows autentication with NTLM.

One of the problems appears to be excessive http 401.2 responses. There are periods where there are five 401.2 responses followed by one 401.1 followed by one 200. This handshake is done for each file requested.

I am wondering if the round robin is causing the extra 401.2 responses.

Improve this question

2 Answers 2

Reset to default
2

Perhaps this is because the auth is bad on each request if you need a stateful connection. I have seen similar things when the load balancer is setup to use round robin. What happens is the ViewState on WSS is authenticated for a server, and the viewstate is encrypted using the machine key. If these keys are not synced on all the servers in the group the view state will be bad, and force a re-authentication... this will keep happening until 2 or 3 requests to the same server happen. The first request is not authorized (request 1), we know this because its a new user, so the next request sends the auth (request 2) and the next sends the request that was sent on request 1 but with a good viewstate (request 3). If at any time in this chain of requests you are sent to another server, it starts over.

Check the system log, do you have a bunch of asp.net errors for bad viewstate? Weird encryption errors? I dont know if WSS catches thos ebefore they hit that log or not, in many .net apps it is not caught and can be seen in the event viewer.

The fix for this is to sync the keys or use sticky.

Improve this answer
1

It's unclear to me if you're talking about round-robin DNS load-balancing or if you're using a layer 7 load-balancer that's doing round-robin load-balancing of the HTTP sessions. It's also unclear if you're allowing clients to use HTTP/1.1 persistent connections to the application servers.

In short, DNS load-balancing shouldn't cause the behavor you're seeing. Layer 7 load-balancing certianly could, especially if you aren't allowing clients to keep persistent connections open to the application servers.

Some amount of 401 responses to client requests in an NTLM-over-HTTP environment are normal. The NTLM-over-HTTP handshake is as such:

  • the client makes a request
  • the server responds with a "401.2 Unauthorized" and a "WWW-Authenticate: NTLM" response header
  • the client responds with another request with an "Authorization: NTLM" header and the initial NTLM authentication response
  • the server responds with a "401.1 Unauthorized" and a "WWW-Authenticate: NTLM" response header that contains the NTLM challenge
  • the client responde with another request with an "Authorization: NTLM" header and the NTLM response
  • the server fulfills the client's request (i.e. they're authenticated)

You can get deeper background at http://www.innovation.ch/personal/ronald/ntlm.html (including byte-for-byte descriptions of the headers, etc).

NTLM-over-HTTP authentication authenticates each connection, so connection keepalives or HTTP/1.1 persistent sessions are required. If, hypothetically, you're not using persistent connections nad randomly bouncing client requests and responses to NTLM challenges between different IIS servers then you're going to have problems (and, frankly, I can't imagine it would even work).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .