3

首先道歉我不能更具体，好像我可以然后我可能知道在哪里看。我有一个 ASP.net Web 应用程序，其中包含一堆使用 AjaxControlToolKit 的页面。我的两个环境之间的页面渲染速度差异很大。一方面~5 seconds，渲染一个相对简单的页面非常慢，该页面有两个网格和一堆控件。我到处看文章都说“检查你的 SQL”，但这不可能是因为 SQL 性能应该在所有环境中都是通用的。我还把它缩小到页面只是做一个基本的回发，没有sql，问题仍然是repro。用户单击全选，我们检查列表中的一堆项目。我为此计时了后面的代码，而且速度很快00:00:00.0002178。

这两个环境并排坐在一起，位置相同，都有 IE9，除了一个在 W2K8 上运行，一个在 W7 上运行。这是唯一真正的区别。在 W7 上，页面的渲染速度相对较快。

任何指针都非常感谢。

编辑：

将调试更改为 false 确实产生了积极影响。

调试页面时间 True 0.143363802770544 False 0.0377570798614921

因此，我接下来要做的是系统地查看应用程序的每个组件，以了解我为什么会犯错误、SQL、ViewState 等。我将为那些感兴趣的人更新我的最终发现。

谢谢大家的帮助！

4

2 回答 2

1

我会检查以下内容

  1. 通过任务管理器（Web 应用程序和数据库）检查服务器上的 CPU 使用率。是不是刷爆了

  2. 服务器的物理内存是否不足 - 再次是任务管理器

  3. 返回的页面是否很大。这很明显，但有时并非如此。绝对数量的 HTML 可以杀死一个页面。这可能是隐藏的（ViewState，带有 display:'none' 的元素）或实际上在页面上，但您已经习惯于看，以至于看不到

  4. 得到小提琴手。您是否调用了任何不应该调用的外部资源。也许您所依赖的 Web 服务突然无法从特定的盒子访问。我们有一个 twitter 提要超时，这完全杀死了一个网站。

  5. 对数据库进行概要分析。你认为不可能，但你确定。你确定你确定。您可能不会在没有意识到的情况下将同类与同类进行比较并在一次测试中带回大量数据。

  6. 某些进程对页面/数据长度非常敏感。例如，我有一个完全失败的正则表达式，一旦页面达到一定大小，页面就会超时。表演几乎没有结束 - 它停止了（写得很糟糕 - 谁做的 - 呃我！！）

  7. 实体盒子是不是快死了。他们是否还有其他正在杀死它的进程/站点。你和谁共享盒子？硬盘是出路了吗？

  8. 防火墙可能很顽皮。通过重新启动物理防火墙，我们看到了性能的大幅提升。你能追踪那些数据包吗？

任何会有更多 - 性能调试可能是一门艺术。但是，嘿-我们都是艺术家，不是吗。

于 2012-05-03T13:30:26.510 回答
0

我可能首先检查我的 web.config 中是否打开了“调试”模式

于 2012-05-03T12:53:35.483 回答