目前我们正在开展云迁移项目，我们对此进行了以下更改：
SQL Server 2014到Azure SQL PaaS
Redis缓存[Windows移植]到Azure Redis PaaS
从共享驱动器到Azure文件服务的静态文件
为数据库交互实施瞬态故障处理。
HttpSessionState已从SQL Server更改为自定义[Redis PaaS]
应用程序有两个使用相同数据库的Web应用程序：
内置经典的网络编码点网编码模型。
使用dot net MVC4构建的另一个应用程序。
在我们将应用程序从现有Rackspace环境[每台4GB RAM的2台服务器]移动到Azure并运行负载测试并收到以下结果之后：
MVC4应用程序的速度要快一些。
Web-Form应用程序开始表现不佳，负载相同， 响应时间从0.46秒增加到45.8秒。
内存使用量相同，数据库利用率约为30％-40％，并且1100个并发用户的 CPU利用率接近100％（所有Web服务器）（在Rackspace，它为4500个并发用户提供服务）
我们测试了应用程序 2 D5 azure服务器虚拟机，RAM越来越高，CPU越来越快。
任何人都可以突出显示如此剧烈的性能下降（一个应用程序表现几乎相同，其他一个表现几乎慢100倍）是可能的吗？
NB：一个观察结果是，即使在停止负载测试30分钟后，CPU利用率仍保持在100％。然后它迅速下降。
答案 0 :(得分：1)
我会强调（强调）您在分析应用程序以识别瓶颈时投入尽可能多的时间和精力。在本地和Azure中运行配置文件，并在可能的情况下进行比较。
您的应用程序显然有许多活动部件和相当大的表面积......这不是犯罪，但它确实意味着很难确定您在没有对运行时行为的一些可见性的情况下所遇到的问题。问题可能在于您的Redis缓存，静态文件处理或会话状态加载/卸载/交互周期。或者它可能在其他地方。这里没有神奇的答案......你需要数据。
那就是说...我已经咨询了几个Azure迁移项目，我的经验告诉我，一个值得关注的领域是ASP.NET Web窗体代码和SQL之间的交互。过于繁琐的应用程序（每个HTTP请求平均多个SQL调用的应用程序）和/或发出在数据库上执行大量逻辑或返回大型结果集的昂贵查询的应用程序往往在Azure等公共云中表现出较差的性能并且数据可能不在同一地点，“噪声邻居”问题可能会影响数据库性能等。这些问题并非Web表单应用程序或Azure所特有，但在旧的遗留应用程序中，它们往往会加剧。假设代码和数据在物理上接近。由于您无法（完全）控制代码和数据相对于彼此存在于Azure中的位置，因此在迁移到云时，可能会在本地场景中掩盖这些问题。
需要考虑的一些细节：
仔细查看Web窗体应用程序中数据绑定的使用......在实践中，它往往会鼓励昂贵的查询并将大型结果集从数据库传输到应用程序，这些内容有时可能会让您失望内部但不在云中
再看一下你的SQL配置...你没有提到你正在使用的是什么级别（基本，标准，高级），但这个选择会对你的整体应用程序性能（和预算）产生重大影响！）。如果事实证明（例如）您的Web窗体应用确实发出了昂贵的查询，那么使用更高层可能有帮助
dated but still relevant advice on Azure migration
如果您可以向我们提供有关瓶颈问题的详细信息，我们可以提供更具体的建议。
祝你好运！
答案 1 :(得分：0)
代码中有一些循环会导致100％的CPU。
发生问题时，从（kudu）处转储。在windbg中分析它 1）用！runaway列出线程cpu时间 2）检查线程的callstack，特别是最大的cpu消费者 〜* e！clrstack和〜* kb