2009-04-30 40 views
2

我们有一个相当复杂的页面,可以动态加载用户控件(其中一些嵌套)。这是一个表现非常慢的页面。ASP.NET页面性能

动态添加控件是否会增加瓶颈?如果我们在.NET缓存对象中添加控件,并且在缓存中已经存在的情况下不使用LoadControl,它会有帮助吗?

任何其他提示/策略使页面更快?

+8

不要猜测。测量。 – 2009-04-30 16:17:54

回答

3

为您的@Page指令添加Trace =“true”,您将能够看到哪些方法花费的时间最长。

0

我怀疑它的动态加载控件的行为是减慢它和更多的每个控件的行为。他们全都碰到数据库吗?我会看看你是否可以在试图优化它们的加载之前简化控件的性能(缓存数据库调用等)。

10

我们曾经将ASP.Net项目的性能提高了一个数量级。以下是我们尝试的一些列表:

  • 尽可能将SessionState设置为false或ReadOnly。请注意,ASPages,Web服务和应用程序的会话状态设置方法不同。
  • 如果可能,将会话状态存储在进程中。
  • 尽可能将EnableViewState设置为false。
  • 尽可能使用缓存。
  • 如果您不需要从服务器访问控件,请使用HTML控件而不是服务器端控件。
  • 尽可能避免往返(向服务器提交数据并重新加载页面)。请注意,您只需往返从服务器读取数据或将数据写入服务器即可。验证和反馈可以在客户端进行。使用Page_Load中的IsPostBack属性可避免回发时重新生成数据。
  • 使用StringBuilder类进行重复连接。
  • 使用try/catch块仅用于意外情况;不要将它们用作一般控制结构。
  • 尽可能使用早期绑定。换句话说,避免反思。
  • 避免非托管代码,如COM。
  • 禁用运输应用程序的调试模式。
  • 使用存储过程进行数据库访问而不是SQL字符串。
  • 使用DataReader类读取数据而不是数据集。
  • 尽可能使用限制性最强的类,如SqlDataReader而不是DbDataReader。
0

我会在页面上做一些分析,看看真正的减速发生在哪里。通常根据我的经验,我认为可能导致实际减速的不是最慢的点。当事情开始运行缓慢时,我发现最好能够剖析我的应用程序/页面,然后给我非常好的信息,说明哪些区域可以加速获得戏剧性的改进。你可能会发现数据库调用太多,或用户控件加载,或者你没有考虑过的其他东西。

1

如果简单地加载控件动态地产生大的性能成本,我会有点惊讶。但是,如果有很多控件,并且它们深深嵌套,则ASP.NET有时会很慢地将它们呈现为html。很显然,按照其他人的建议来确定你的瓶颈究竟在哪里。

对于一个复杂的页面来说,检查呈现的html的大小是一件事。有了许多服务器控件,页面大小可以快速攀升到几兆字节。打开或调整http压缩可能是您正在寻找的答案。

1

调查性能问题的第一步是确定瓶颈:它是网络流量(太多的HTTP请求?太多的HTML来自管道?)或CPU绑定在服务器上?或数据库调用过多?

在许多情况下,页面的大小会导致速度减慢。如果你在页面上包含很多控件,那么会有很多HTML,所以如果你在最终的渲染产品上查看源代码并找到20000行HTML/javascript,那么很可能是因为减速太多数据通过网络发送。

我建议使用像YSlow这样的工具来帮助您更好地理解最终呈现的产品。

关键项目看:

  • 管理视图状态的大小
  • 制作所隐藏的设置。可见页面的确定部分=假(而不只是风格=“显示:无; “)
  • 集中和合并的javascript
  • 最小化HTTP请求的数量
1

装载用户控制动态绝对不是性能下降的原因。通常阻碍ASPX页面性能的一件事就是viewstate。我建议将视图状态从页面中移出[即使您已经在某些控件上启用了它]。

将完整的viewstate存储为服务器上的会话变量,并仅在viewstate字段中传输标识符。您可以查看完整的文章here,文章还提供了性能度量指标。

0

网页的缓慢表现有很多原因。你真的需要使用一些像性能向导这样的工具来开始了解正在发生的事情。

我们最新的性能问题归结为匿名类型和linq。由于所有的JIT编译都在进行,所以用这两件事情来杀死性能是非常容易的。