- Client connects to an Azure Web Sites website
- ARR runs on the front-end Azure server and receives the request
- ARR decides to which of the available instances the request should go
- ARR forwards the request to the selected server, crafts and attaches an ARRAffinity cookie to the request
- The response comes back to the client, holding the ARRAffinity cookie.
- When the client receives the request, it stores the cookie for later use (browsers are designed to do this for cookies they receive from servers)
- When the client submits a subsequent request, it includes the cookie in it
- When ARR receives the request, it sees the cookie, and decodes it.
- The decoded cookie holds the name of the instance that was used earlier, and so ARR forwards the request to the same instance, rather than choosing one from the pool
- The same thing (steps 7-9) repeat upon every subsequent request for the same site, until the user closes the browser, at which point the cookie is cleared
However, there are situations where keeping affinity is not desired. For example, some users don’t close their browser, and remain connected for extended periods of time. When this happens, the affinity cookie remains in the browser, and this keeps the user attached to his server for a period that could last hours, days or even more (in theory, indefinitely!). Keeping your computer on and browser open is not unusual, and many people (especially on their work-place computers) do it all the time. In the real world, this leads to the distribution of users per instance falling out of balance (that’s a little like how the line behind some registers in the supermarket can get hogged by a single customer, leading to others waiting in line more than they normally should). Depending on your applications and what they do, you may care more or less about users being tied to to their servers. In case this is of little or no importance and you’d rather disable this affinity and opt for better load balancing, we have introduced the ability for you to control it. Because the affinity is controlled by an affinity cookie, all you have to do to disable affinity is make sure that Azure doesn’t give the cookies out. If it doesn’t, subsequent requests by the user will be treated as “new”, and instead of trying to route them to “their” server, ARR will use its normal load-balancing behavior to route the request to the best server. This is how the affinity cookie looks:
Disabling the affinity can be done in two ways:
- In your application
- In a site configuration
* This example is for C#, but this could just as easily be done in any other language or platform. Setting this in the application’s code would be suitable for situations you DO want affinity to be kept for the most part, and only reset on specific application pages. If, however, you prefer to have it completely disabled, you could have ARR remove the cookie always by having IIS itself inject that header directly. This is done with a customHeaders configuration section in web.config. Simply add the following into your web.config, and upload it to the root of the site: Keep in mind, though, that the configuration in web.config is sensitive, and a badly formatted file can stop the site from working properly. If you haven’t had a chance to work with web.config files before, read this getting-started guide. Troubleshooting If you intend on implementing this, you might wonder how to confirm its working and troubleshoot it. The ARR Affinity cookie is normally included with the 1st response from any Azure Web Sites web site, and subsequently included with any request sent from the client and response received from the server. To see it in action, you could use any of multiple HTTP troubleshooting and diagnostic tools. Here is a list of some of the more popular options:
- Network Monitor