我们最近将新版本的Web应用程序部署到了生产环境，并对相对较高的流量页面进行了一些重大更改，这些页面加载了各种抵押产品。自部署以来，此产品页面从7秒增加到10秒，加载到50秒到2分钟。此外，由于我们的IIS工作进程（w3wp.exe 32）在我们的专用生产Web服务器上运行，因此CPU利用率现在经常被最大化。这种不可接受的严重性能损失仅在“产品”页面上发生，而不在任何其他页面上发生。
我在服务器上运行DebugDiag.exe，持续时间超出CPU使用率。罪魁祸首又是我们的产品页面。我们在正常工作时间内平均有60个用户，在高峰时段，最大化的CPU显着减慢了其余的Web应用程序页面加载速度。我们得到偶尔的http错误代码501，表示服务器过载＆amp;请求失败。
我运行了Chrome开发工具＆gt;网络＆gt;捕获并看到（例如）一个请求只获取产品页面本身（248k）需要24秒，然后几个20kb图像和JavaScript文件的后续请求需要更长时间（每个24到50秒）总计页面加载时间为1.9分钟（转移850k，请求总数为93，DOMContentLoaded = 1.2分钟）。
我认为这种实质性的降低并不是因为这个新版本中固有的低效asp.net或SQL代码更改（不用担心我试图为自己覆盖;反正它不是我的代码; - ））。为了实现这一理论，我注意到，在浏览器中加载大量产品页面内容之后，Chrome会发出另一个获取请求（http://ourcompany.com/ productpage.aspx？ImageControl_ctl00 $ ctl00 $ cphMainBodyFrame $ ImageCompanyLogo = 1）对于12k公司徽标，它位于主页asp.net ImageControl中。此请求平均需要40秒才能完成。因此，徽标直到游戏后期才会出现。
我在产品页面上运行了Telerik的JustTrace asp.net分析工具我的本地DEV环境，尽管对数据库和数据访问层进行了大量调用，但在性能瓶颈方面却没有明显的变化。然后我将上面的徽标URL粘贴到地址中，同时在JustTrace中进行分析，并看到完成了最小的处理以检索该徽标。 Asp.net内部只调用两个存储过程到成员资格数据库来验证用户，以及一些其他次要系统调用。尽管最小的asp.net和存储过程。电话，徽标的要求花了太长时间;并且仅适用于“产品”页面。
这可能是会话锁定问题吗？此外，这些年来我已经阅读了数以千计的SO帖子，这是我的第一篇文章。多年来感谢SO社区的所有支持。这是一个非常宝贵的资源。
Win Server 2008 R2（v6.1 Build 7601：SP1） - [具有8个CPU核心的VM＆gt; 32GB内存] IIS（7.5.7600.16385） ASP.NET 4.0 WebForms MSSQL Server 12
答案 0 :(得分：0)
答案简短：
我们使用的是Infragistics asp.net控件版本12.2.20122.2031，它适用于旧版浏览器。升级到版本12.2.20122.2257（也支持旧版浏览器），不仅完全解决了我们产品页面的问题，而且在网站性能方面产生了极大效果。
答案很长：
在Web服务器CPU达到最大限度的持续时间内，我能够获得正在运行的进程的快照。我使用工具（DebugDiag）来分析快照，并生成了一个冗长的详细信息报告，其中Infragistics GetLicense（）函数需要最多的CPU资源。它看起来像这样：http://i.stack.imgur.com/6BRAS.png
我联系了Infragistics对此的支持，他们指示我们使用版本12.x.2257控件，他们说这些控件可以解决性能问题。我们在DEV环境中升级了Infragistics dll，整个站点平均每页加载6-15秒，达到2-3秒。更新面板异步回发也很快完成。
我们担心由于升级我们在整个应用程序中一致使用的控制集可能引起的问题而导致的任何风险。如果我们的C＃代码在后面的代码中动态创建控件，则在Infragistics日历控件中手动键入日期时，测试升级会显示IE DocMode = IE7的小问题。
为什么我们使用DocMode IE7
我们的网络应用程序是在IE7的辉煌时期构建的。公司发展迅速，许多开发人员必须编写大量代码，这些开发人员已经过去了。从来没有决定摆脱对IE7的依赖，因此大部分应用程序在IE DocMode = IE7下运行。这意味着只有传统的Infragistics asp.net控件（版本＆lt; = 12.x）与我们的站点兼容。如果版本大于12.x，我们会遇到日历控件的显示问题。
总之;如果这种情况听起来很熟悉，请升级您的控件并说服管理层不惜一切代价摆脱IE7依赖。
