在数据库支持的 Web 应用程序中，对性能最重要的影响是什么？答案

【问题标题】：What is the most important effect on performance in a database-backed web application?在数据库支持的 Web 应用程序中，对性能最重要的影响是什么？
【发布时间】：2010-02-11 01:59:04
【问题描述】：

最近有人要求我加快 C#/ASP.NET/SQL Server 业务应用程序网站的速度。由于我刚开始，我对内部的了解并不多。那么我从哪里开始呢？看不见的东西，在这样的系统上影响性能的最重要的事情是什么？数据库调优？硬件？个别页面优化？首先你会看什么？

编辑：在我实际完成工作后，我会回来发布答案。 ;)

再次编辑：“个人资料”目前是投票最多的答案，我同意这显然是人们应该做的。但我一直在寻找关于分析结果会显示什么的猜测/经验，所以我认为这个答案并不重要......

【问题讨论】：

这是一场比赛吗？我们都猜测问题出在哪里，如果我们猜对了，我们会得到一个 cookie 和一个复选标记？
整个网站不就是这样吗？除了没有 cookie...
有点意思，但想法是让有用的信息不与一个案例相关联。也就是说，解决问题的最佳答案应该是获得最多票数和复选标记的人，而不是碰巧猜到你的具体情况的人。

标签： c# asp.net sql-server performance

【解决方案1】：

首先你会看什么？

分析器。

【讨论】：

很公平...分析什么？ SQL 查询、在服务器上执行的代码、客户端 javascript、请求.. ?
@Scott：是的。分析这些东西。
我会从 RedGate ANTS 或 JetBrains dotTrace 开始，然后在所有 C# 代码上运行它。热点在数据库中的位置，您会看到它显示为对 System.Data 层的调用。热点在 C# 代码中的位置会显示给您。它对客户端层没有帮助，但它会向您显示客户端是否发出过多或过于频繁的请求，这至少会为您指明正确的方向。

【解决方案2】：

我要做的第一件事是获取 JetBrains 的 dotTrace 应用程序的副本，并使用它来分析网站。不要对性能问题所在的位置做出假设 - 去找出答案！

【讨论】：

dotTrace（没听说过）与 IBM Rational Quantify（我在 C++ 应用程序中广泛使用）相比如何？
@Scott：我没用过 IBM 产品，所以不知道。

【解决方案3】：

我首先要看的是数据库，确保索引应该有索引。

【讨论】：

【解决方案4】：

任何事情都可能是问题所在。获取一个表现不佳的页面并跟踪控制流程。使用调试器和 sql 分析器并查看该页面所做的一切。应该很清楚要解决什么问题。

请记住从用户因速度慢而感到沮丧的页面开始。不要打扰其他页面（例如登录页面，这几乎从来不是问题。）

当然，如果您有经验，您只需查看代码 (DB + .NET) 即可知道问题所在，但您没有经验。因此，另一种选择是聘请有经验的顾问。

编辑 - 我的猜测（因为我想要一个 cookie）

如果是 AJAX，它可能是 JavaScript
否则很可能是 TSQL
除非程序员不知道如何使用 TSQL，而只是拉入整个 DB 表并在 C# 中操作数据
或者程序员对页面模型（或 MVC 模型）一无所知，这是你一生中见过的最离奇的代码。

这些我都看过了。

【讨论】：

我支持霍根的提议。从这里开始的另一件好事是分析为什么这个特定页面运行缓慢，您将开始更好地理解应用程序的内部结构（至少层，理论上所有页面应该是相同的，数据库结构，或者至少是其中的一部分，以及代码风格）。这将帮助您在此之后调整其他页面。如果可能的话，我肯定会考虑在页面中添加一些检测代码（知道理论上这可能会使它变慢）并使用 SQL Profiler 作为理解数据库的工具。
@Wagner：谢谢——是的，这是迄今为止最适合初学者的计划。这样做你会学到很多东西@Scott
@downvoter：总是很高兴在没有任何解释的情况下投反对票。

【解决方案5】：

使用分析器是衡量性能的好方法，但如果您不对生产性能进行合理的模拟，则会很棘手。

大多数由 DB 支持的 Web 应用程序都受 I/O 限制而非计算限制。如果没有分析器，我会猜测查询性能。您可以通过运行解释查询播放来确定您需要哪些索引来提高查询性能。或者通过将结果集/活动记录放入缓存来避免优化查询。

【讨论】：

【解决方案6】：

对于数据库部分，这是一个好的开始：

Troubleshooting Performance Problems in SQL Server 2005

但如果您发现无效的客户端代码，我也不会感到惊讶。尤其是在与数据库通信时。

【讨论】：

【解决方案7】：

事实证明，最严重的问题是一些麻烦的页面，它们用数千个 SQL 查询冲击数据库。代码看起来比较单纯，只是一些数据绑定的网格。然而，C#/LINQ 对于它（或我们）自身的好处来说有点太强大了：如果你将一个网格绑定到一个表，但网格想要显示另一个通过外键链接的表中的字段，它就可以了！但它通过运行无数个查询来做到这一点：

SELECT ... FROM other_table WHERE Id = 1
...
SELECT ... FROM other_table WHERE Id = 2
...
SELECT ... FROM other_table WHERE Id = 3
...
SELECT ... FROM other_table WHERE Id = 4
...

等等...通过确保绑定到控件的数据集包含所有必要的数据而无需重新查询数据库，问题明显得到缓解。

现在回到分析...

【讨论】：

【解决方案8】：

根据我的经验，我会投票支持数据库锁定问题。

【讨论】：