C# 将Azure网站改进为Azure VM网络延迟

我有一系列的

Azure网站

，它们部署到与运行SQL server的

Azure虚拟机相同的
资源组
，据我之前所知，这是确保您的进程在地理位置上彼此接近所需的全部

但是，我遇到了一些严重的性能问题。在运行类似这样的简单代码时使用
Entities Framework

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

或者像这样简单的

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

或者，我的本地开发设置和生产系统之间的平均性能差异是400%。这种差异在不同类型的查询中似乎是相当一致的，并且在这个问题上抛出了一个更大的VM。这显然不是一个硬件问题，因为它没有任何影响。虽然我预计会有一些网络延迟，但这似乎非常高

我做错了什么？如果有人能提供Azure网站和Azure虚拟机之间通信的最佳实践以及如何改善延迟的详细信息，我将不胜感激

旁注：在我的研究过程中，我发现你可以创建Azure虚拟网络（并假设这可能是解决方案的一部分），但我看不到将网站移动或关联到此类虚拟网络的方法。
Maxim。
这个评论我已经看过好几次了。Microsoft发布了一些在Azure中使用实体框架的指南。你可以在这里找到它：


这也许不是你问题的最佳答案，但我相信它会对你大有帮助。对我来说确实如此

另外，如果可能的话，我会考虑一种温和的CQRS实现，这样你就可以创建两个上下文对象，一个用于写作，另一个用于阅读。在只读上下文中，您可以关闭EF中的跟踪，从而显著提高EF的整体读取性能

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

我希望这些都能有所帮助
 衷心感谢您的意见，但与您提到的其他问题（我自己也看到了一些问题）不同，我的问题根本不同。我的问题不在于实体框架，我可以通过尝试应用您描述的一些优化来轻松验证这一点，但几乎没有效果。此外，如果这是一个EF问题，我希望在我的开发机器上，而不仅仅是在生产中，也会出现同样的行为。我的问题似乎在于Azure云的网络拓扑，不幸的是，您没有解决它。网络拓扑就是它。它是为水平规模（多台机器）而不是垂直规模（一台机器上有更多CPU/RAM）而构建的。此外，您或多或少被迫一直考虑异步，这可能需要一些调整。每个人在将他们的开发环境与云（任何云）进行比较时都会受到最初的冲击，但一旦你克服了最初的冲击并开始利用它，你就再也不会回头了。-承诺：）请验证你已经在同一区域部署了所有项目。使用同一资源组并不保证所有资源都位于同一区域。来自文档：“5-资源组可以包含驻留在不同区域的资源。”