In the demo used in part one of this article series, we have seen the geographical routing methods. Here, we will see the performance routing method. For that, you have to change the routing method to performance in the dashboard of the Azure Traffic Manager.
Here, it may work geographically also in some cases according to the performance. Now, let’s see what will happen if one of them failed. For demonstration, what I am doing here is removing all the pages from the India end-point so that it can’t run. I can simply do it by using the console window from the portal itself.
On doing this, if you came back to the portal, you can see that the monitoring status of India is degraded.
And if you try the same URL from your machine, you see the response from USA instead of India, as while checking, the Server has gotten no response from the India end-point.
One more thing that you have to take care of here is TTL. The duration of the cache is determined by the 'time-to-live' (TTL) property of each DNS record. Shorter values result in faster cache expiry and thus more round-trips to the Traffic Manager Name Servers. Longer values mean that it can take longer to direct traffic away from a failed end-point in case of any failure and will result in being locked-in. Traffic Manager allows you to configure the TTL used in Traffic Manager DNS responses, enabling you to choose the value that best balances the needs of your application.
Here, it is 300 seconds that means - go to selected end-point and have the communication directly until 5 minutes. It will check back with the Traffic Manager only after 5 minutes.
The next thing you have to take care of is the monitoring settings. The only way Traffic Manager checks whether an end-point is up and running is by querying the port 80 for the root page. As we know, whenever we request a web page and it loads, it gets an HTTP protocol code 200 which is for OK.
So, whenever a Traffic Manager gets a 200 code, it will consider it as healthy and good to go. Here, in our demo, the root page is default.html which is a simple web page without any complexity. In case it is connected to a database and even if the database fails, the page will give a response of 200 which will make the Traffic Manager think that the node is healthy, and that will assign it to the Server. So here, we have to apply some logic on another page to load and display only if all other connected resources are working, link the page here, and mention that page in the path section.
Here, health.aspx will return the code 200 only if all the connected resources are working and Traffic Manager will check the response from this page only.