企业 Web 应用程序的 .NET 性能提示答案

【问题标题】：.NET performance tips for enterprise web applications企业 Web 应用程序的 .NET 性能提示
【发布时间】：2008-11-14 21:04:22
【问题描述】：

对于企业网络应用，每一点都很重要。

您可以分享哪些性能技巧来帮助程序员更高效地编程？

开始：

在字符串上使用 StringBuilders，因为字符串是可变的（每次修改它们时都会重新创建）。
避免使用数据集，因为它们非常臃肿，请改用 SqlReader。

【问题讨论】：

您提出的两点并非特定于网络应用程序；它们代表任何 .NET 应用程序。
或者他们会爱上任何 .NET 应用程序——在我看来，这两者听起来都让代码的可读性降低了。我宁愿在一周中的任何一天都使用强类型的 DataSet（或类似的抽象）而不是原始的 SqlReader。
为什么要标记 F#？此外，关于 #1 - 由于您引用的原因，字符串是不可变的。
erik，不知道他们为什么要添加 F#？
“因为字符串是可变的” - 我可能会感到困惑，但那不应该是“字符串是不可变的”吗？我认为 immutable = 在构造函数运行后无法修改，但我不确定并且太累了现在无法查看它:)

标签： .net asp.net performance

【解决方案1】：

问题中的要点是微优化。我不同意“每一点都有帮助”的前提——尤其是当它以牺牲可读性为代价时。

您看，如果您能够真正轻松地阅读和理解您的代码，这意味着您可以轻松地进行架构更改。这些才是真正的大胜利所在，而不是微优化。你越是尝试调整每一行代码，就越难重构整个设计。

所以我的建议是：

尽可能写出可读性最强的代码
不要过早地优化实施 - 而是尽早考虑架构性能问题
在你有确切的数字来判断你是否正在改进之前，不要更改性能的名称
使用分析器帮助发现瓶颈

到目前为止，这些都不是特定于网络应用程序的。对于网络应用（以及一般的服务器端）：

除非您真的知道您永远不需要超过一台服务器，否则请确保您的代码可以水平扩展。如果您有能力这样做，开始使用两台（或更多）服务器，这样您就可以及早解决任何问题（会话等）。这也有助于滚动升级等。

编辑：我根本没有处理数据库。 Kyle's answer 在这方面做得很好。如果可能，请确保您的数据库也可以扩展:)

【讨论】：

【解决方案2】：

您将在（几乎）任何应用程序中看到的最大收益是调整您的数据库。

编码 ...

您是否只需要 2 列而选择了 12 列？
您是否正在获取所有结果以执行 SUM？
您是否要抓取 1,000 条记录以显示 10 条？
您是否每页都触发了一百个查询？

数据库 ...

您的表上有索引吗？
它们是正确的索引吗？
您是否使用 SQL Profiler 获取了一些示例查询并在 Query Analyser 中检查了它们的执行计划？
您是否看到 TABLE SCAN - BAD！
您是否看到 INDEX SEEK - 好！

如果所有其他方法都失败了，请缓存其中的垃圾并在问题上投入更多硬件！ :)

【讨论】：

不要忘记：您是否在针对大型表的查询中看到 CONVERT() - 非常糟糕！！！

【解决方案3】：

我们每天都在处理这个问题。

我们确实缓存了一些经常使用的数据集。我们有一个相当复杂的数据层缓存机制，非常适合我们。

对几乎所有内容的惰性评估。

用户控件的页面缓存和部分缓存

我们根本不使用会话状态，所以我们完全禁用了它。

将网站配置为以已知的低权限用户身份运行。

以相同的低权限用户身份连接到 SQL Server。这有助于连接池 - 所有连接都基本相同。

没有临时 SQL。仅存储过程。有助于执行和 SQL 注入。

string.Concat() 代替 string + string + ... 或 StringBuilder

【讨论】：

string.concat 在我猜的幕后使用了一个字符串生成器？从未听说过低权限的“技巧”？
不，string.Concat 不使用 StringBuilder。但是 string + string + string 只是调用 string.Concat...
请记住，Linq-to-SQL 也可以防止 SQL 注入。并且使用存储过程与参数化查询相比几乎没有优势，因为它们都使用相同的方法来缓存执行计划。
“低权限”用户没有真正的魔力 - 只是无能为力。例如，它所能做的就是执行 procs，所以如果有人以某种方式劫持网站并尝试对 SQL 进行一些讨厌的事情，他们除了调用程序之外什么也做不了 - 执行动态 DML，没有 DDL（表删除等）

【解决方案4】：

除了 manwood 没有人提到 ViewState，这很令人惊讶。我将 ViewState Management 选为性能改进的最重要考虑因素。

我的清单：

积极管理视图状态
UpdatePanel 是邪恶的 ;) 合理使用
利用 jQuery 等 JavaScript 框架
观看您的服务器往返
使用异步页面进行 IO 绑定操作
不同级别的缓存同样重要（页面级别、数据等）
使用 Ajax “按需”获取数据并在本地缓存为 XML（XML 数据岛等）
考虑对长时间运行的操作进行异步处理（您可以使用基于数据库的作业队列并通过 Windows 服务对其进行处理。ajax 请求可以监控行的完成情况并使用气球更新 UI）

编辑：[添加 6-8]

【讨论】：

【解决方案5】：

Microsoft 出版了一本名为Improving .NET Application Performance and Scalability 的书。这是一本必读的书。

【讨论】：

这是从 2004 年开始的。从那时起，.NET Framework 确实发生了很大变化。在您看来，这本书是否仍然是最新的并且值得一读？只是检查。谢谢。

【解决方案6】：

除了数据库之外，还有一个非常重要的值得关注的事情......

页面大小和请求数。这不言而喻，但众所周知，ASP.NET 不擅长用一堆废话输出（增加大小）和创建一百万个外部脚本文件（请求数）来填充您的页面。

【讨论】：

【解决方案7】：

尽可能少地访问数据库
尽可能少地访问 web.config
正如曼伍德所说，充分利用缓存。我还可以建议阅读 this 关于内核模式缓存的非常好的文章
尽可能避免锁定
现在有些事情（比如数据排序）可以在客户端完成（参见 Jquery）
here 是一篇值得阅读的好文章

【讨论】：

【解决方案8】：

尽可能少地回帖。当用户做出一组复杂的标准选择时，使用 DHTML 和 JavaScript 来操作页面。不要发回帖子来更改页面以响应每个小的用户设置。
尽可能少用 ASP.NET 控件。尽可能使用纯 html。由于视图状态和控件状态，所有 ASP.NET 控件都是有代价的。纯 HTML 没有这种开销。我曾经为花旗银行做过一个网络应用程序，它由一个主查询页面组成。这个页面比较复杂。它只有一个 ASP.NET 控件。这是一个回传按钮，用于制作自定义 Excel 表格，加载用户选择的数据。
使用 MVC 框架而不是 ASP.NET。如果您使用 Brail 或 NVelocity，则视图状态和控件状态不在此处。
在您的后端代码上运行 Redgate 软件的 Ants Profiler。确保您的回发事件尽可能简短而温馨。
如果页面从每 24 小时或每周刷新一次的表中派生数据，则不要在每次用户发出请求时编写通用 ASP.NET 页面来查询数据。如果数据是静态的，则也将页面设为静态。您可以使用 XML 文字和 Linq to XML 类在 NT 调度程序的基础上生成静态页面。这是我能给你的最大加速。

【讨论】：

【解决方案9】：

对于不经常更改但经常使用的任何数据，请充分利用缓存对象。如果您需要使缓存对象与数据库保持一致，请查看 SqlCacheDependency。
在不需要的地方禁用 ViewState

【讨论】：

【解决方案10】：

检查日志并尽量减少每个请求提供的 HTML 数量。 viewstate 和臃肿的第三方控件可能会破坏您的应用程序。例如，我们长期使用来自基础设施的网格。非常非常有能力，但即使是剥离形式，它也制作了大约 60-90k 的页面 + 大量的 java 脚本。这严重限制了我们可以处理的请求数量，即使在内部千兆连接上也是如此。

【讨论】：

【解决方案11】：

根据我的经验，以下几点会产生很大的不同：

使用 SQL Server Profiler 识别运行缓慢的查询。尤其要使用调优模板来查看您是否错过了任何索引。
合理缓存（缓存应用程序块）
密切关注 ViewState
使用 Fiddler 检查页面大小等

【讨论】：

【解决方案12】：

如果您的网络服务器正受到大量同时请求的冲击，并且每个页面请求似乎需要越来越长的服务时间，您可能需要考虑转换为异步页面处理模型。

Scalable Apps with Asynchronous Programming in ASP.NET

【讨论】：