生产服务器中asp.net网站的性能提升器

Question

我在生产服务器上有一个asp.net webforms应用程序，它真的很慢。所以我决定从我的SO用户那里获得一些性能提示。

我已应用这些来增加我的asp.net网站性能，

1. 设置debug=false
   

2. 转动off追踪
   

3. 图像缓存

          <caching>
           <profiles>
               <add extension=".png" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" location="Any" />
               <add extension=".jpg" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" location="Any" />
               <add extension=".gif" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" location="Any" />
           </profiles>
       </caching>
   

你知道其他任何真正的表演助推器吗？任何建议......

Answer 1

网页只有设计才能快速。

一个简单的选项无法使您的页面加载速度更快。 debug = off只消除了额外的调试功能，实际上如果你不使用它们就不会让很多人想到。

我同意保罗所说的一切，你可以found them here with more details而且我必须多说...

你需要遵循一些指南并做很多工作才能使它们真正快速。 我关注的是什么。

1. 我使用（自定义）缓存进行数据库操作，这确实提高了数据加载速度，但同时使代码更多，我花了很多时间。
2. 我在页面上使用分析器查找我的慢点并更正它们。
3. 我使用Google Chrome浏览器上的检查器来查找缓慢加载和双重加载问题。
4. 我在自定义控件上消除了对任何变量的双重使用/创建。
5. 我在this suggestions上的客户端浏览器上使用缓存。
6. 我使用 webfarm 和/或 webgarden （多个游泳池）。

如何查看您的网页速度：http://code.google.com/speed/page-speed/docs/using.html

优化缓存：http://code.google.com/speed/page-speed/docs/caching.html

谷歌的许多一般主题都可以在这里找到：http://code.google.com/speed/articles/

关于缓存：http://www.mnot.net/cache_docs/

希望得到这个帮助。

Answer 2

不是直接ASP.NET，而是

1）确保在IIS中启用压缩。

2）如果您的网站是一个单独的域内的cookie“重”主机静态文件（图像，CSS和JS）。每个返回服务器的请求都需要将所有站点cookie信息发送回服务器。因此，如果您的cookie使用量为10kb +，则页面中的20个静态文件引用将导致额外的200kb被发送回服务器。如果将静态文件移动到没有cookie要求的域，则可以消除此开销。值得注意的是，由于IE处理事务的“错误”，您在使用子域时没有任何好处，IE似乎坚持将所有域cookie发送到子域。这样做的另一个好处是允许更多HTTP requests in parallel

Answer 3

停止攻击您的生产服务器（可能会引入功能性错误）并退后一步。您能否在非生产环境中重现性能问题？如果没有，那么就去做尝试。

您应该尝试按如下方式重现问题：

• 在您的测试环境中获取生产级硬件 - Web和数据库服务器等 - 运行与生产相同的硬件
• 运行与生产相同的软件集 - 这包括相同的ASPNET配置和所有其他使用的服务。
• 将生产规模数据（如果可能的话，生产数据）加载到您的数据库中（记得从互联网上防火墙实验室，以便它不能将邮件或其他东西发送到互联网，或者您的用户可能会开始接收来自测试的电子邮件通知系统哪个不好！）
• 创建网站到生产级别的模拟流量 - 这可能相当棘手，但有很多工具可用

现在你有机会在测试中重现问题，你可以尝试解决方案。

通常数据库驱动的网站会受到数据库的瓶颈，所以我从那里开始。主要技巧是

• 执行更少的查询
• 优化您要执行的查询（获取更少的数据，使用适当的索引等）
• 更改数据库结构，以便您必须执行的查询更容易（聚簇索引等，可能是非规范化）

但是你做的任何改变，在测试系统上尝试，测量结果，如果没有帮助，请回滚。

一般来说，配置更改可能只会产生细微差别，但您也可以尝试这些。

---

如果所有这些听起来都太费劲，那么试着抛出硬件来解决问题 - 开发人员的时间比硬件贵得多。在您完成上述操作的时间（可能是数月，取决于应用程序的复杂性），您可能已经购买了一些内容丰富的生产箱。但请确保它会有所帮助。

您的数据库是否适合RAM？它可能适合于ram吗？如果这些问题的答案分别为no和yes，请为数据库购买更多ram。这是在没有代码更改的情况下使数据库速度更快的最便宜的方法之一。