昨天的性能优化与今天的网站故障

     为了面对博客园越来越大的访问量的挑战,这几天我专心于博客园网站的性能优化。
     前天试验了用空间换时间的生成静态html文件的方法,感觉整体性能提高不是很明显,而且增加了程序的复杂度,并带来了一些新问题。
     昨天,我又回到了对网站程序本身的优化。性能优化的目标是减少内存消耗。博客园的程序与数据库运行在同一台在服务器上,内存只有2G。节省内存是提高性能的重要因素。内存的两个大用户当然是Web应用程序与数据库, 所以性能优化从两方面着手,一是减少Web应用程序的内存占用,二是减少数据库查询,从面减少数据库占用的内存。昨天优化时,我发现了数据库中一张表的索引有问题。在代码中,发现了一处地方应该使用缓存减少数据库查询,却没有使用。我纠正了这两个问题。
     同时,我也对machine.config的设置进行了调整,调整时参考了:
     1、Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications
     2、IIS 6.0 Tuning for Performance
     需要修改的参数如下:
 Configuration setting             Default value (.NET Framework 1.1)     Recommended value
maxconnection 2 12 * #CPUs
maxIoThreads 20 100
maxWorkerThreads 20 100
minWorkerThreads   50
minFreeThreads 8 88 * #CPUs
minLocalRequestFreeThreads 4 76 * #CPUs

     maxWorkerThreads、maxIoThreads、minWorkerThreads是processModel的属性,maxconnection是connectionManagement中的一个属性,minFreeThreads 、minLocalRequestFreeThreads是httpRuntime 的属性。 
     这里我遇到一个问题,博客园的服务器算一个CPU还是两个CPU(你也许会想这算什么问题),物理CPU的确只有一个,可这不是一个普通的CPU, 是超线程CPU(超线程现在也很普通,呵呵)。从操作系统的任务管理器、设备管理器以及SQL Server企业管理器中看到的都是两个CPU。所以以前我是按照两个CPU来设置的,并且没有设置minWorkerThreads。昨天,我改成了单CPU设置,并且设置了minWorkerThreads,但设置成了一个不推荐的值:100。(我设置时看错了推荐值,不知是否是这个设置引起了今天的服务器故障)
     
     继续优化,在网上看到一篇Tips for ASP.NET Application Performance Enhancement ,其中提到一点“Avoid Throwing Exceptions.”,这让想到在博客园程序中,当用户访问一个不存在的地址时,会抛出异常BlogDoesNotExistException,然后在Error.aspx页面显示异常信息,这个地方我一直觉得不存在性能问题,但我突然想到,假如网上有什么软件大量访问博客园不存在的地址,会产生很多异常,这时可能会带来性能问题,处理这些异常,需要消耗一些资源,仅仅为了显示异常信息而消耗昂贵的资源,太不值得了。 对于这样的情况,直接重定向到一个错误提示页面就行了,没必要抛出异常。博客园网站占用内存过多的问题可能这也是罪魁祸首之一。我立刻对代码进行改进,在重定向时,我没有指向错误页面,而是指向了博客园首页(在解决一个性能问题时,来了另外一个性能问题,博客园首页是访问量最大的页面,将无效地址访问重定向到首页,给首页带来更大的压力)。 
      
     做这些优化之后,我更新了服务器上的程序。更新后,系统运行正常,让我惊喜的是,内存占用降了下来,原来w3wp进程正常需要占用600多M内存,高的时候甚至800多M,现在基本上在500M左右。 
     
     今天早上,当我准备享受优化的成果时,现实却跟我开了个玩笑,9:00左右,有人反映不能访问自己的Blog, 而访问博客园首页正常,我查看了一下错误信息内容为: 
     CS1595: 已在多处定义“_ASP.Calendar_ascx”;使用“c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\blog\49be8ecb\4a239ba\ejndjhfs.dll”中的定义。 

     这个错误是在加载Blog页面上的日历控件时出现的。奇怪,这里的代码昨天没有修改,以前也没出现过这个问题,在另外一目录中并且是另外的命名空间,的确有一个同名的控件,可以前一直运行正常,怎么今天就会出现问题? 后来我把该日历控件Codebehind中的类改名才解决问题(两个同名的类在不同命名空间, 怎么会有问题?奇怪)。

     而这个时候,服务器CPU一直100%负荷运行,大部分CPU被数据库占用了,访问网站很慢,经常出错。用SQL Server的事件查看器跟踪,很多存储过程执行时间很长。重启IIS、数据库索引优化、重启服务器,都没能解决问题,后来恢复了以前的程序, 还是没解决问题,接着我将machine.config按照两个CPU进行设置,并删除了minWorkerThreads设置。最后,我修改了程序,将无效地址访问重定向到一个静态页面,并更新服务器,经常两个多小时的奋战,在11:30左右才让博客园恢复运行。
     究竟是什么原因引起这次故障?我现在也搞不明白,进行了那么多处理,究竟是哪个因素是关键?现在也无法判断。我需要投入更多精力对网站进行性能优化。就写到这吧,继续研究博客园网站的性能优化。有兴趣的朋友,欢迎在博客园一起研究高性能Web应用程序开发。
posted @ 2005-10-12 15:52 dudu 阅读(5261) 评论(40)  编辑 收藏 网摘 所属分类: 网站性能优化

  回复  引用  查看    
#1楼 2005-10-12 16:14 | 浪淘沙      
呵呵,有限的资源下更能考究网管的能力了。也更有机会研究性能优化。
  回复  引用  查看    
#2楼 2005-10-12 16:17 | Cdo      
刚才又遇打不开cnblogs的情况了,说有什么错误。现在又好了,真是happy。

希望老大的优化能给大家带来更好的服务:)
  回复  引用  查看    
#3楼 2005-10-12 16:29 | 小迪      
好像有点卡
  回复  引用    
#4楼 2005-10-12 16:49 | lone [未注册用户]
.net 1.1 最高也无法使用到2G的内存的吧
依照我们以前的经验,一般将iis设置成 800M左右自动回收内存比较合适
SQL server 设置成使用固定的内存~


  回复  引用    
#5楼 2005-10-12 17:05 | ocean [未注册用户]
想想我们16G的内存,我们都不知道该怎么用,和dudu相反,我们是想办法往内存里面塞东西,真是现实的玩笑。
dudu真是辛苦,不过这种优化也确实可以学到很多知识。值。
  回复  引用  查看    
#6楼 2005-10-12 19:12 | sm160.com      
我认为大哥想办法降低内存占用不是个好办法?

我认为你还是得走让所有动态页面变成静态页面的方向走...

>> 前天试验了用空间换时间的生成静态html文件的方法,感觉整体性能提高不是很明显,而且增加了程序的复杂度,并带来了一些新问题。

不太同意你的上述观点, 采用静态html文件一定会提高性能的, 怎么会不明显呢? 真是搞不懂.
程序当然是要复杂一些, 但我认为你可以不必修改原来的程序, 而是写一个公用的接口程序, 根据URL管理器自动去识别要不要生成HTML文件, 然后再写个JOB, 定时清理一些过期的HTML文件...

个人建议, 供大哥参考.
  回复  引用  查看    
#7楼 [楼主]2005-10-12 21:11 | dudu      
@sm160.com
你说的有道理。
目前有些访问量很大的页面由于有部分内容是必须是动态的(比如发表评论的表单), 生成html文件就会有问题。如果能解决这个问题, 静态html当然是提高性能的有效方法。目前正在尝试在一些页面使用生成html文件的方式。
  回复  引用  查看    
#8楼 2005-10-12 22:27 | 小力      
我的博客现在又打不开了
http://jonlee.cnblogs.com/
  回复  引用  查看    
#9楼 [楼主]2005-10-12 22:40 | dudu      
@小力
现在好了。

晕! 已在多处定义“_ASP.Calendar_ascx”竟然是web.config中<compilation defaultLanguage="c#" debug="false"/>引起的, 改为debug="true"就好了。
  回复  引用  查看    
#10楼 2005-10-12 23:05 | 工业酒精      
web.config中<compilation defaultLanguage="c#" debug="false"/>引起的, 改为debug="true"就好了


这个问题刚想提出,DUDU就发现了,哈哈。。。。

我们的项目也是,刚开始上去,CPU总是在80%以上,然后看了一篇文章提到一定要关闭debug模式,果然,CPU将近降低了30个百分点

而且每次本地编译调试速度也快
  回复  引用  查看    
#11楼 [楼主]2005-10-12 23:14 | dudu      
可现在使用debug="true" 会出现"已在多处定义“_ASP.Calendar_ascx"问题。
  回复  引用  查看    
#12楼 [楼主]2005-10-13 00:00 | dudu      
使用debug="true" 会出现"已在多处定义“_ASP.Calendar_ascx"的问题已经解决。
  回复  引用    
#13楼 2005-10-13 06:27 | Wuvist [未注册用户]
donews/csdn的blog使用的也是.Text……
前段时间也有将页面静态化以应付流量增长……
或者,dudu可以联系看看他们是如何解决的?
donews/csdn的程序应该都是韩磊改的……
http://blog.csdn.net/grhunter
  回复  引用  查看    
#14楼 2005-10-13 08:17 | 81      
把首页缓存5秒,系统的必须应该有不错的提高,因为这个页面是访问最多的。
  回复  引用  查看    
#15楼 [楼主]2005-10-13 09:17 | dudu      
@Wuvist
现在很多页面使用了html文件进行缓存。

@81
首页缓存1分种。
  回复  引用    
#16楼 2005-10-13 09:17 | REvol [未注册用户]
博客园面对的挑战已经进入另一个阶段了,可喜可贺。
  回复  引用  查看    
#17楼 2005-10-13 09:25 | 81      
建议在首页上加一个访问计数器,记录总的访问次数,当日访问次数,日最高访问次数。
  回复  引用  查看    
#18楼 [楼主]2005-10-13 09:32 | dudu      
首页有啊!
  回复  引用  查看    
#19楼 2005-10-13 09:33 | sm160.com      
>> 关于: 使用debug="true" 会出现"已在多处定义“_ASP.Calendar_ascx"的问题已经解决。

好像这种问题我以前也碰到过, 我当时的经验并不是改config, 而是重启机器. 后来发现如果你的命名空间发生变化, 再用新程序更新老程, 就会出现一些怪问题, 解决的办法是在更新之前一定要删除BIN下面的DLL, 这时再更新就没有问题了.

还有导出程序时, 记得不要把CONFIG包含在里面, 不然每次都得改debug很麻烦的.

>> 目前有些访问量很大的页面由于有部分内容是必须是动态的(比如发表评论的表单), 生成html文件就会有问题。

我的思路是: 主体页面依旧采用HTML, 局部的评论内容可以采用xmlhttp的方式用javascript结合xml动态生成即可.
  回复  引用  查看    
#20楼 2005-10-13 09:39 | sm160.com      
>> 晕! 已在多处定义“_ASP.Calendar_ascx”竟然是web.config中<compilation defaultLanguage="c#" debug="false"/>引起的, 改为debug="true"就好了。

如果处在调试模式debug="true", 哪不是运行更慢啊? 你可以试着把:debug="false"再改回去保存, 我估计依旧是正常的.
  回复  引用  查看    
#21楼 2005-10-13 09:41 | t_98dsky      
我也遇到了网站性能方面的问题,cpu访问的人多的时候有90%的时间是100%(日访问ip3,4万左右,大概也是十多万点击),,但是w3wp.exe占用只有200多MB,SQL也是400多MB..进程那里显示的是SQL占用的CPU老是很高,晕!有什么优化方面的文章可以提供一个吗?


  回复  引用  查看    
#22楼 [楼主]2005-10-13 09:43 | dudu      
现在在博客园首页、各网站分类页面、个人Blog首页及随笔分类、随笔档案、文章分类、文章页面档案使用了Html文件进行缓存。
  回复  引用    
#23楼 2005-10-13 09:45 | t_98dsky [未注册用户]
忘了说,我的站点也是很多页面都用静态的了,用到sql查询的也只有前台的不多的地方和后台管理系统.
  回复  引用  查看    
#24楼 2005-10-13 10:19 | flower.b      
debug="true" CSC.EXE编译的时候不会“自动优化”。

在我尝试捕捉编译器错误时发现,如果debug="true" 则csc.exe编译参数是: “/D:DEBUG /debug+ /optimize-”,反之是:“/debug- /optimize+”
命名冲突可能就是因为:“/optimize+”。建议DUDU反编译ejndjhfs.dll看看真正的原代码。或者捕捉编译错误的原代码(可能会很大,呵呵) 。(个人猜想优化应该是使用了类似 “using 类名称=XXX.XXX.XXX;” 形式引用引起的,因为这样优化后“类名称”很容易冲突,Resharper就是这样优化。)

cnblogs的首页DUDU可否尝试过使用生成shtml的方式解决?使用SSI需要IIS做的工作很少,效率很高。同时也能避免一次生成太多内容,只要生成shtml用到的一部分就可以。但是这样的工作也会带来很大工作量。
  回复  引用    
#25楼 2005-10-13 10:23 | t_98dsky [未注册用户]
刚才访问出现了不少错误,一会是服务器忙,一会是超时,....dudu还要^@^!
  回复  引用  查看    
#26楼 2005-10-13 10:25 | flower.b      
另外还建议DUDU“偷偷”记录每个页面的执行时间(或者记录大于某时间的页面),找出最费资源的页面,然后再想办法优化。前几天有个项目,本来也以为是首页占用资源最大,后来首页生成静态HTML资源占用仍然很高,最后找到是一个页面程序有问题。
  回复  引用    
#27楼 2005-10-13 11:10 | 81 [未注册用户]
好主意
  回复  引用  查看    
#28楼 [楼主]2005-10-13 11:14 | dudu      
我先解决debug="false"的问题。
  回复  引用  查看    
#29楼 2005-10-13 11:45 | 工业酒精      
还有就是编译的时候要采用Release模式,好像
  回复  引用  查看    
#30楼 [楼主]2005-10-13 12:30 | dudu      
@工业酒精
已经采用Release模式。
  回复  引用    
#31楼 2005-10-13 17:10 | 柚子Nan [未注册用户]
I remember this tool, AntProfile can be used to track every page's performance.
  回复  引用  查看    
#32楼 [楼主]2005-10-13 18:08 | dudu      
@柚子Nan
在网上没找到这个工具, 是不是名称弄错了?
  回复  引用    
#33楼 2005-10-13 21:38 | Allen [未注册用户]
我们网站也有性能问题,不知道像Alibaba这样的网站是怎么解决这个问题的。
  回复  引用  查看    
#34楼 2005-10-14 00:18 | 风之翼      
考虑监视性能计数器,对分析程序应该有所帮助
· Process
· Thread
· Processor
· Memory
· .NET CLR Data
· .NET CLR Exceptions
· .NET CLR Interop
· .NET CLR Jit
· .NET CLR Loading
· .NET CLR LocksAndThreads
· .NET CLR Memory
· .NET CLR Networking
· .NET CLR Remoting
· .NET CLR Security
· ASP.NET
· ASP.NET Applications
  回复  引用  查看    
#35楼 2005-10-18 14:47 | steeven      
回复部分采用innerframe不可以吗?通过js和父页面交互。
这样每页就不用动态生成了
  回复  引用  查看    
#36楼 2005-12-15 22:39 | 卡卡.net      
我遇到了那个问题,其实就是 那些 dll文件的缓存问题,重启IIS就OK
  回复  引用  查看    
#37楼 2006-02-10 15:36 | 雁儿飞飞      
还是首页先html,其他的慢慢来
  回复  引用    
#38楼 2006-04-13 15:01 | cai5cai5 [未注册用户]
最近网站服务器遇到了一些问题:

错误现象: 访问网站时,出现站点忙的错误。
查看事件日志, 发现下面的错误内容:
来源: ASP.NET 1.1.4322.0
事件 ID: 1003
描述:
aspnet_wp.exe (PID: 3092) was recycled because it was suspected to be in a deadlocked state. It did not send any responses for pending requests in the last 180 seconds. This timeout may be adjusted using the <processModel responseDeadlockInterval> setting in machine.config.

而且进程下的aspnet_wp.exe和DLLHOST.exe占用的内存一直涨!

请帮忙分析一下原因!
  回复  引用  查看    
#39楼 2006-07-10 16:52 | Sunny      
  回复  引用  查看    
#40楼 2008-09-19 13:58 | 小小部落      
恩,学习了




标题  
姓名  
主页
Email (博主才能看到) 
验证码 *  看不清,换一张 [登录][注册]
内容(请不要发表任何与政治相关的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
该文被作者在 2005-10-13 09:39 编辑过
Google站内搜索

China-pub 计算机图书网上专卖店!6.5万品种 2-8折!
近千种 9-95 新二手计算图书火热销售中!
开发者征途系统新作:《设计模式——基于C#的工程化实现及扩展》

相关文章:

相关链接: