Asp.net Azure应用程序服务Web应用程序资源和用户控件加载缓慢

我们刚刚开始在Azure环境中部署托管的web应用程序。我们的数据库作为Azure SQL数据库运行，web应用程序作为Azure应用程序服务web应用程序运行（包括一个连续的WebJob）。我们在Web应用程序中遇到了一些重大的性能问题，我希望得到一些关于如何解决这些性能问题的建议

以下是一些要点：

• Web应用程序部署为已编译的Web应用程序（二进制文件、标记、*.resx文件），而不是源代码
• Web应用程序是通过FTP部署的
• 该Web应用已启用“始终打开”
• 应用程序服务正在美国中南部Azure数据中心运行
• Azure SQL数据库也在美国中南部Azure数据中心运行（因此数据库延迟应该最小）
• 我们有一个Web应用的精确副本（相同的二进制文件等），运行在洛杉矶数据中心的非Azure服务器上（如果数据库延迟是问题，则此站点的数据库延迟会更差）
• Web应用程序的两个实例（Azure和非Azure）都连接到同一个Azure SQL数据库（在美国中南部Azure数据中心运行）
• 我一直在犹他州的一个工作站上进行测试——不是特别靠近这两个web服务器

在任何“冷”请求（站点已经空闲了一段时间）中，Azure站点似乎要慢得多。从非Azure服务器快速加载的页面需要Azure服务器花费很长时间（例如20秒或更长时间）。内容是一样的，两个应用程序访问的是同一个数据库，所以我不认为这是数据库问题。我已将其缩小为两个似乎是问题所在的.NET函数：

System.Web.UI.TemplateControl.GetLocalResourceObject（字符串） System.Web.UI.TemplateControl.LoadControl（字符串）

该应用程序包括一些不同语言的*.resx文件。当请求传入时，它使用请求头中的区域性来加载正确的资源。GetLocalResourceObject函数似乎正在动态编译*.resx文件，在Azure服务器上这似乎需要几秒钟的时间。我可能需要尝试一些类似的方法来阻止Azure动态编译*.resx文件

我们的一些页面动态加载控件，因此调用LoadControl方法。这些控件被部署为*.ascx标记，但隐藏的代码已编译到.\bin文件夹中的*.dll中。尽管控件已经编译，但LoadControl函数似乎正在尝试编译每个控件，这在Azure服务器上需要几秒钟的时间

Azure服务器上的“热”页面访问速度似乎更快（几乎与非Azure服务器一样快），可能是因为资源和控件已经编译并仍在内存中。我还无法确定在什么时候必须重新编译资源/控件

我试图找出最好的方法，使网站响应良好，即使是在“冷”的要求。我已经尝试在Azure应用程序服务服务器上运行（通过Kudu CMD）。这有时似乎有效，但并不十分可靠（有时似乎不起作用，或者过程似乎没有完成）。而且，即使在编译站点之后，问题似乎也会在闲置一段时间后再次出现

---

我们的主要目标是让Azure应用程序服务Web应用程序的性能达到可接受的水平。似乎唯一的方法是强制Web应用程序预编译资源和用户控件，这样它们就不会按需编译。我还没有找到一个可靠的方法来实现这一目标。如果有任何帮助或见解，我们将不胜感激。

您有没有想到这一点？我遇到了同样的问题我们在构建过程中运行了aspnet_compiler.exe，然后将预编译的应用程序部署到Azure Web应用程序。这并不完全方便，但似乎有效。