When analyzing traffic from a web application such as CRM you may notice that many of the requests result in a 401 (Access Denied) before they get the 200 Success response. This is a normal authentication sequence for Kerberos or NTLM. Internet Explorer will first attempt anonymous access before any type of authentication attempts.
Some of the static objects, such as graphics, will allow anonymous access so the request immediately gets a 200 response; other objects such as ASPX pages require authentication before the content is returned. In that case, we have two round-trips before we get our data. This can result in many extra round trips to load an entire page. If the users are on a WAN or if there is high latency on the network the performance may be impacted. On some custom pages, I have seen one 401 for every 200 which doubled the round-trips to load page.
IIS 6.0 and IIS 7.0 require the client to be reauthenticated for each HTTP request, which causes network traffic to increase. The following KB articles describe fixes you can apply to change this behavior. When the fix is applied the client will authenticate on the first request and then remain authenticated for the remaining requests in that HTTP Keep-Alive session. This can greatly decrease the round-trips and amount of data being transferred.
http://support.microsoft.com/kb/917557
http://support.microsoft.com/kb/954873
In the following example the customer had a custom page displayed on their contact form. After applying the fixes the total round-trips decreased by 40%. Each environment is a little bit different, but there may be some performance gains found by testing these fixes.
Sample Results after Applying Changes from the KB:
BEFORE
AFTER
Percent Change
Request Count: 126
Request Count: 76
-40%
RESPONSE CODES
HTTP/200: 64
0
HTTP/401: 62
HTTP/401: 12
-81%
Hi there, does this have any impact on the security event log (Audit logon/off) such as reducing the number of events?
This should not have any impact on that. These authentication attempts wouldn't be logged in the windows event viewer security log.