Search code examples
azureazure-sql-databaseazure-web-app-serviceazure-traffic-manager

Improve CPU Utilization by Restructuring Nodes


We have a database located in North Europe region with 2 nodes of AppServices on Azure (West Europe & North Europe). We use traffic manager to route traffic.

Our SQL database and storage are located in Northern Europe.

When we started the website, European locations were the closest to our customers.

However, we saw a shift and most of our customers now are from USA.

We have high CPU utilization on our processors although we have a lot of instances on each.

The question is:

Since most of our customers are from USA and it's hard to relocate the database, is it better to keep the app structure as it is (N. Europe & W. Europe) or create a new node in USA but this node will still need to communicate with the database in North Europe?

Thank you


Solution

  • Having you app in US region and Database in Europe is not recommended.

    These are a few of the things you will run into:

    1) High latency since the queries for data will have to round-trip to Europe to get this.

    2) Higher resource utilization since in general each request that access the DB will take longer, this will increase memory usage while requests are waiting on data it will also make the impact of load a lot more severe on the app.

    3) cross region data egress, you will need to pay for all the data moving from Europe to us every-time there is a query.

    A better solution would be to do the following:

    1) Setup a new DB in us region and hook up active geo-replication

    At this point you will have a hot/cold configuration where any instance can be used to read data form the DB but only the primary instance can be used for write operations.

    2) Create a new version of the App/App Service plan in US region

    3) Adapt your code to understand your geo distributed topology.

    You App should be able to send all reads to the "closest" region and all writes to the primary database.

    4) Deploy the code to all regions

    5) add the new region to TM profile

    While this is not ideal since write operation might still have to jump the pond, most apps have a read write patter than is heavily askewed towards read operations (roughly 85% reads / 15% writes ) so this solution works out with the added benefit of giving you HA in case one of the regions goes down.

    You might want to look at this talk where I go over how to setup a geo distributed app using App Service, SQL Azure and the technique outlined above.