首先道歉我不能更具体，好像我可以，然后我可能知道在哪里看。我有一个ASP.net Web应用程序，其中包含一堆使用AjaxControlToolKit的页面。页面呈现的速度在我的两个环境之间差别很大。在一个方面，使用~5 seconds呈现一个相对简单的页面有两个网格和一堆控件，这是非常慢的。在任何地方，我看文章都说“检查你的SQL”，但这不可能是因为SQL perf应该在所有环境中都是通用的。我还把它缩小到页面只是做一个基本的帖子回来，没有sql，仍然问题是repro。用户单击全选，我们检查列表中的一堆项目。我为此设置了代码，并且速度很快00:00:00.0002178。
两个环境并排，相同的位置，都有IE9，除了一个在W2K8上运行，一个是W7。这是唯一真正的区别。在W7上，页面相对快速呈现。
任何指针都非常感激。
编辑：
将调试更改为false确实产生了积极的影响。
调试页面时间 真0.143363802770544 错误0.0377570798614921
接下来我要做的是系统地查看应用程序的每个组件，看看我犯错误的原因，SQL，ViewState等等。我会为那些感兴趣的人更新帖子和我的最终发现。
谢谢大家的帮助！
答案 0 :(得分：1)
我会查看以下内容
通过任务管理器（Web应用程序和数据库）检查服务器上的CPU使用情况。是否超出
服务器是否超出物理内存 - 再次是任务管理器
返回的页面是否庞大。这是显而易见的，但有时并非如此。大量的HTML可以杀死页面。这可能是隐藏的（ViewState，带有显示的元素：'none'）或实际上在页面上，但您已经习惯于看不到了
让小提琴手进入它。你是否打电话给任何你不应该做的外部资源。也许有一个你依赖的网络服务突然无法从特定的盒子中访问。我们有一个Twitter提要，超时完全杀死了一个网站。
对数据库进行概要分析。你认为它不可能但是你确定。你确定你确定吗？您可能没有比较喜欢，并且在没有实现的情况下在一次测试中带回大量数据。
某些进程对页面/数据长度非常敏感。例如，我有一个完全失败的正则表达式，并在页面达到一定大小后将页面计时。表演几乎没有结束 - 它已经停止了（写得很糟糕 - 谁做到了 - 呃我！）
物理盒子是否正在死亡。他们是否正在杀死它的任何其他进程/站点。你和谁分享这个盒子？它上面的硬盘就出来了吗？
防火墙可能很顽皮。通过重新启动物理防火墙，我们已经看到了性能的大幅提升。你能跟踪那些数据包吗？
任何会有更多 - 性能调试可能有点艺术。但是嘿 - 我们所有的艺术家都不是我们。
答案 1 :(得分：0)
我可能首先检查一下我的web.config中是否启用了'debug'模式