Maxim Gershkovich
Maxim Gershkovich

Reputation: 47179

Improving Azure Website to Azure VM network latency

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.

Upvotes: 1

Views: 168

Answers (1)

Pedro G. Dias
Pedro G. Dias

Reputation: 3222

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.

Upvotes: 1

Related Questions