什么原因导致页面渲染缓慢？

Question

我很困惑。根据我的老板说法，导致页面部分加载并在postback时“跳转”到记忆滚动位置的页面调用的跟踪让我感到困惑。

最终通过我的跟踪发现，我的整个加载时间从开始预初始化到结束呈现需花费1.94秒，其中1.5秒花费在开始预呈现和结束预呈现之间。

你有什么想法可能会造成这种情况吗？下一个最大的加载时间是0.14秒，用于结束预渲染完成。

可能问题来自我对SQL Server的查询或页面上过多的控件，即使大多数控件是“隐藏”的？

[编辑：]当我展示特定表单时，似乎我的页面加载非常缓慢。我的总呈现大小为91537字节，其中44483字节专用于该特定表格。我的视图状态似乎非常巨大。此外：404 JS文件是否会导致这种加载滞后？

[更新：]所以我找到了运行时间最长的查询，尽管它确实看起来相当复杂，但它已经在页面加载之前结束运行了。 作为附加信息：我在控件中使用了相当多的SqlDataSources，以填充我的下拉列表和其他有趣的内容。这会使我的应用程序混乱吗？

- Olivier Tremblay

---

阅读你的更新后，我仍然认为你需要在分析器中查看这个问题才能确定。 - Saul Dolgin

Answer 1

根据我的经验（和你遇到的问题相同），这很可能是SQL问题导致的，占总问题的90%。

在你调用的查询语句周围放置一些 Stopwatch（计时器），以确定哪个查询运行缓慢。

渲染 ASP.NET 控件不应该花费太长时间……

- Davide Vosti

---

渲染ASP.NET控件可能需要很长时间，考虑到控件可能非常复杂（想想一些Telerik ajax组件等）。 - Saul Dolgin

我同意这个观点。特别是当你使用任何数据源控件的时候。运行SQL Profiler同时运行应用程序。 - NotMe

哦，所以SQLDataSource不是一个好主意？ - Olivier Tremblay

我认为这取决于您检索的数据量。如果您的查询只返回一堆（多达数百个）SQLDataSource仍然很好。使用分析器调整查询，并确保仅检索您在页面上显示的数据。如果您100％确定查询运行快，请查找其他地方。 - Davide Vosti

终于找到罪魁祸首了：它是一个查询。谢谢你:P - Olivier Tremblay

Answer 2

为了找出瓶颈的原因，你真的应该使用像ANTS Profiler这样的工具对你的代码进行剖析。

剖析器将通过显示哪些代码行比其他代码行慢来帮助您定位问题区域。

- Andrew Hare

---

有没有什么办法不用花400美元就能找到这个应用程序中的一个问题？ :P - Olivier Tremblay

我觉得你可以通过下载 ANTS Profiler 来尝试它 :). 同样，你可以下载 Visual Studio 试用版，免费使用 VS 分析器。 - Jimmy Chandra

我使用了ANTS Profiler的试用版以及Visual Studio的性能向导，发现它们在许多方面都是可比较的。 - Saul Dolgin

ANTS只是一个建议 - 还有许多其他选择。这个网站有很多关于.NET分析器的问题。 - Andrew Hare

Answer 3

我会使用 YSlow 来确定是客户端还是服务器端的问题。有时我们会在某些查询中添加计时器，然后将执行时间输出到HTML注释中...当测试完成时，当然要删除它们。

这个页面是否调用任何外部站点托管的内容？

- Chris Klepeis

---

如果问题可以追溯到preinit和endrender之间的某个地方，那么在这种特殊情况下，yslow可能无能为力。但我同意它仍然是一个好工具，并且是对标题中更通用问题的相关答案。 - David Hedlund

Answer 4

你最好使用Visual Studio中的性能向导，并查看页面的调用树。它将为您提供有关确切性能瓶颈的更多详细信息。

当页面上声明了太多复杂控件时，我曾经见过这种类型的性能问题。虽然它也可能与SQL相关。要确定，您需要查看调用树，并找出最昂贵的调用是什么。

- Saul Dolgin

Answer 5

当然，如果涉及SQL，正如许多人所指出的那样，“SQL Server Profiler”是要使用的工具（假设您正在运行MSSQL）。 MySQL有“JetProfiler”（.com），我还没有尝试过。一旦找到缓慢的查询，通常是索引问题。

- David Hedlund