我们有一个相当复杂的页面,可以动态加载用户控件(其中一些嵌套)。这是一个表现非常慢的页面。ASP.NET页面性能
动态添加控件是否会增加瓶颈?如果我们在.NET缓存对象中添加控件,并且在缓存中已经存在的情况下不使用LoadControl,它会有帮助吗?
任何其他提示/策略使页面更快?
我们有一个相当复杂的页面,可以动态加载用户控件(其中一些嵌套)。这是一个表现非常慢的页面。ASP.NET页面性能
动态添加控件是否会增加瓶颈?如果我们在.NET缓存对象中添加控件,并且在缓存中已经存在的情况下不使用LoadControl,它会有帮助吗?
任何其他提示/策略使页面更快?
为您的@Page指令添加Trace =“true”,您将能够看到哪些方法花费的时间最长。
我怀疑它的动态加载控件的行为是减慢它和更多的每个控件的行为。他们全都碰到数据库吗?我会看看你是否可以在试图优化它们的加载之前简化控件的性能(缓存数据库调用等)。
我们曾经将ASP.Net项目的性能提高了一个数量级。以下是我们尝试的一些列表:
我会在页面上做一些分析,看看真正的减速发生在哪里。通常根据我的经验,我认为可能导致实际减速的不是最慢的点。当事情开始运行缓慢时,我发现最好能够剖析我的应用程序/页面,然后给我非常好的信息,说明哪些区域可以加速获得戏剧性的改进。你可能会发现数据库调用太多,或用户控件加载,或者你没有考虑过的其他东西。
如果简单地加载控件动态地产生大的性能成本,我会有点惊讶。但是,如果有很多控件,并且它们深深嵌套,则ASP.NET有时会很慢地将它们呈现为html。很显然,按照其他人的建议来确定你的瓶颈究竟在哪里。
对于一个复杂的页面来说,检查呈现的html的大小是一件事。有了许多服务器控件,页面大小可以快速攀升到几兆字节。打开或调整http压缩可能是您正在寻找的答案。
调查性能问题的第一步是确定瓶颈:它是网络流量(太多的HTTP请求?太多的HTML来自管道?)或CPU绑定在服务器上?或数据库调用过多?
在许多情况下,页面的大小会导致速度减慢。如果你在页面上包含很多控件,那么会有很多HTML,所以如果你在最终的渲染产品上查看源代码并找到20000行HTML/javascript,那么很可能是因为减速太多数据通过网络发送。
我建议使用像YSlow这样的工具来帮助您更好地理解最终呈现的产品。
关键项目看:
装载用户控制动态绝对不是性能下降的原因。通常阻碍ASPX页面性能的一件事就是viewstate。我建议将视图状态从页面中移出[即使您已经在某些控件上启用了它]。
将完整的viewstate存储为服务器上的会话变量,并仅在viewstate字段中传输标识符。您可以查看完整的文章here,文章还提供了性能度量指标。
网页的缓慢表现有很多原因。你真的需要使用一些像性能向导这样的工具来开始了解正在发生的事情。
我们最新的性能问题归结为匿名类型和linq。由于所有的JIT编译都在进行,所以用这两件事情来杀死性能是非常容易的。
不要猜测。测量。 – 2009-04-30 16:17:54