Improving Azure Website to Azure VM network latency

Question

I have a series of Azure Websites that are deployed to the same Resource Group as an Azure VM running SQL server, as far as I previously understood this was all that was required to ensure that your processes are located in a geographically close proximity to each other.

However I have run into some steep performance issues. Using Entities Framework when running a simple bit of code like this

var result = await Context.Settings.Where(o => o.Name == name).FirstOrDefaultAsync();

or a something as simple as

var result = await context.Categories.Include(o => o.ParentCategory);

or some combination of the above the average performance difference between my local dev setup and the production system is 400%. This difference seems fairly consistent across different types of queries and having thrown a bigger VM at the problem it definitely seems this is not a hardware issue as it had no effect. While I expected some network latency this seems extremely high.

What am I doing wrong? I would sincerely appreciate if someone could provide a breakdown of best practices for communications between Azure Websites and Azure VMs and how to improve latency.

Sidenote: In the process of my research I have found that you can create Azure Virtual Networks (and assume this might be part of the solution) but I cannot see a way to move or associate a Website onto such a Virtual network.

Please, verify that you have deployed all your items in the same region. Using the same Resource Group does not guarantee that all is in the same region. From documentation: "5 - A resource group can contain resources that reside in different regions." azure.microsoft.com/en-us/documentation/articles/… — Fabrizio Accatino

Pedro G. Dias Pedro G. Dias · Accepted Answer · 2016-06-06T04:46:31

Maxim. I've seen this comment a couple of times. Microsoft posted some guides for working with Entity Framework in Azure. You can find it here:

https://msdn.microsoft.com/en-us/library/cc853327(v=vs.110).aspx

It may not be the best answer to your question, but I believe it should help you greatly. It certainly did for me.

Additionally, I would, if possible, consider a gentle kind of CQRS implementation, such that you make TWO context objects, one for writing and a different one for reading. In the read-only context, you're able to turn off tracking in EF, which significantly improves EF read performance overall.

// In your READ context, do this in the constructor
context.Configuration.AutoDetectChangesEnabled = false;

I hope any of this helps.

Improving Azure Website to Azure VM network latency

1 Answers