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

时间:2008-11-14 21:04:22

标签: .net asp.net performance

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

您可以分享哪些性能提示来帮助程序员更有效地编程?

开始吧:

  1. 对字符串使用StringBuilders,因为字符串是可变的(每次修改它们时都会重新创建)。

  2. 避免使用数据集,因为它们非常臃肿,请改用SqlReader。

12 个答案:

答案 0 :(得分:24)

问题中提出的观点是微观优化。我不同意“每一点点都有帮助”的前提 - 特别是如果以牺牲可读性为代价。

您知道,如果您能够轻松阅读和理解您的代码,那意味着您可以轻松地进行体系结构更改。那些是真正的大赢家,而不是微优化。你试图调整每一行代码的次数越多,就越难以重构整个设计。

所以我的提示是:

  • 编写最易读的代码
  • 不要过早优化实施 - 但要及早考虑架构性能问题
  • 在你用硬数据告诉你是否改善事情之前,不要改变表演名称
  • 使用分析器帮助发现瓶颈

到目前为止,这些都不是针对网络应用的。对于Web应用程序(以及一般的服务器端):

  • 除非您确实知道您永远不需要多台服务器,否则请确保您的代码可以横向扩展。如果你有能力这样做,启动两个服务器(或更多),这样你就可以尽早解决任何问题(会话等)。这也有助于滚动升级等。
编辑:我根本没有解决数据库问题。 Kyle's answer在这方面表现很好。如果可能,请确保您的数据库也可以扩展:)

答案 1 :(得分:15)

你将会看到(几乎)所有应用程序中最大的收益是调整数据库。

编码......

  • 当您只需要2时,您是否选择了十几列?
  • 您是否抓取所有结果来执行SUM?
  • 您是否抓取1,000条记录以显示10?
  • 你每个页面都会发出一百个查询吗?

数据库......

  • 你的桌子上有索引吗?
  • 它们是正确的索引吗?
  • 您是否使用SQL事件探查器获取了一些示例查询并在查询分析器中检出了他们的执行计划?
  • 你看到TABLE SCAN - BAD!
  • 你看到INDEX SEEK - GOOD!

如果所有其他方法都失败了,请将其中的狗屎缓存出去并为此问题投入更多硬件! :)

答案 2 :(得分:3)

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

我们会缓存一些使用过的数据集。我们有一个相当复杂的数据层缓存机制,对我们很有用。

几乎所有事情的懒惰评估。

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

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

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

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

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

string.Concat()而不是string + string + ...或StringBuilder

答案 3 :(得分:3)

除了曼伍德,没有人提到ViewState,这是非常令人惊讶的。我会将ViewState Management视为性能提升的最重要考虑因素。

我的清单:

  1. 积极管理视图状态
  2. UpdatePanel是邪恶的;)使Juridicious使用
  3. 利用JavaScript框架,例如jQuery
  4. 观看您的服务器往返
  5. 使用异步页面进行IO绑定操作
  6. 各个级别的缓存同样重要(页面级别,数据等)
  7. 使用Ajax“按需”获取数据并在本地缓存为XML(XML数据岛等)。
  8. 考虑长时间运行操作的异步处理(您可以使用基于数据库的作业队列并通过Windows服务处理它们.ajax请求可以监视行以完成并使用气球更新UI)
  9. 编辑:[已添加6-8]

答案 4 :(得分:2)

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

答案 5 :(得分:1)

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

答案 6 :(得分:1)

除了数据库之外,另一个非常重要的事情要看......

页面大小和请求数量。这应该是不言而喻的,但是ASP.NET充斥着大量垃圾输出(增加大小)并创建了一百万个外部脚本文件(请求数量),这是非常糟糕的。

答案 7 :(得分:1)

  • 尽可能少地回复。使用DHTML&用户在制作一组复杂的critera选项时操纵页面的JavaScript。不要回发以在页面中进行更改以响应每个小用户设置。
  • 尽可能少地使用ASP.NET控件。尽可能使用普通的HTML。由于视图状态和控件状态,所有ASP.NET控件都需要付出代价。纯HTML没有这种开销。我曾经为花旗银行做了一个网络应用程序,它包含一个主查询页面。这个页面中等复杂。它只有一个ASP.NET控件。这是一个贴回来制作自定义Excel工作表的按钮,加载了用户选择的数据。
  • 使用MVC框架而不是ASP.NET。如果您使用Brail或NVelocity,则View态和控制状态不在此处。
  • 在您的后端代码上运行Redgate软件的蚂蚁分析器。确保您的回发活动尽可能简短和甜蜜。
  • 如果页面从每24小时刷新一次或每周刷新一次的表中导出数据,请不要在每次用户发出请求时编写一个comon ASP.NET页面来查询数据。如果数据是静态的,也要使页面保持静态。您可以使用XML literals&amp ;;在NT Scheduler的基础上生成静态页面。 Linq到XML类。这是我能给你的最大速度。

答案 8 :(得分:0)

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

答案 9 :(得分:0)

检查日志并最小化每个请求所服务的HTML数量。 viewstate和臃肿的第三方控件可能会破坏您的应用程序。例如,我们长时间使用了来自infragistics的网格。非常有能力,但即使在它的剥离形式,它使页面大约60-90k +很多java脚本。这严重限制了我们可以服务的请求数量,即使是在内部千兆位连接上也是如此。

答案 10 :(得分:0)

根据我的经验,以下内容有很大不同:

  • 使用SQL Server Profiler识别运行缓慢的查询。特别是使用调优模板来查看是否错过了任何索引。
  • 明智地缓存(缓存应用程序块)
  • 密切关注ViewState
  • 使用Fiddler检查页面大小等。

答案 11 :(得分:0)

如果您的Web服务器受到大量并发请求的攻击,并且每个页面请求似乎需要更长时间的服务,您可能需要考虑转换为异步页面处理模型。 / p>

Scalable Apps with Asynchronous Programming in ASP.NET