关于try catch资源消耗的思考

今天在写网站后台的时候,突然想到这个问题,因为try catch是要耗费系统资源的,如果在所有的比如数据库操作的方法都加上try catch,那一个页面一般需要跑几次数据库,这其中就会浪费不算很多也不是非常少的系统资源,如果网站的流量到达相当大的程度,那服务器恐怕就会不堪重负了。
原来跟一个朋友聊过,他说他们的站点不加try catch,保证程序不出错,所有的地方都进行if 相关的判断,尤其是数据库上,这样就不会有这个问题,但我想如果数据库服务器出了问题(比如停电或者类似的问题吧),那页面就是一个除了程序员之外都看不懂的错误信息了,这也是没法避免的。
所以我想是不是应该在不使用try catch来捕捉错误的情况下每次都去判断一下数据库的情况,就是在每个页面打开时都去连接一下数据库,如果能连上就证明没有问题,那在程序也保证没有问题的情况下就可以保证没有出错信息出现,同时也避免了使用try catch带来的资源消耗。但这又带来了其它的资源消耗,就是这个每个页面开始都要做的连接数据库,但我觉得相比你一个页面平均要使用几次try catch带来的资源消耗而言应该还是差一些的,况且这部分的消耗应该是转移到了数据库服务器上,程序服务器的消耗减轻了,如果本身程序服务器的负担比较重我觉得可以采用这种方法。
不知道大家一般都怎么看这个问题,采取什么方法来保证程序不出错同时又能够最大程度减轻服务器负担。
本人才疏学浅,想就这个问题跟大家讨论一下,放在首页希望大家轻点拍。我是第一次发文。

posted on 2007-07-24 11:36 biglee 阅读(3111) 评论(37) 编辑 收藏

评论

#1楼 2007-07-24 19:44 lovecherry      

出异常就让他出啊,网站可以采用统一的方式处理异常(比如记录),然后给用户重定向到出错页面。 也可以直接用 customErrors啊  回复 引用 查看   

#2楼 2007-07-24 19:45 补丁      

想完全避免出错?这种尽善尽美的想法,既没有这个必要也不太有可能.
微软自己的错误就不少
实际上,全部try catch,该出错还是出错,只是你捕捉到了错误,仍然无法处理所有的错误,数据库连接不上你能怎么样?
asp.net本身就给了你捕捉错误的能力,重载page的OnError方法就可以捕捉和处理页面错误,然后给用户以比较友好的反馈.
其实....完全避免错误也有办法...生成静态页面,这东西出错几率小...
 回复 引用 查看   

#3楼[楼主] 2007-07-24 19:48 biglee      

@lovecherry
要想捕捉到异常还是要用到try catch语句吧,那就还是要有给try catch分配的服务器资源消耗,这个东西还是挺费资源的吧,我就是想避免这种情况,尤其是访问量大服务器就更吃不消了吧
 回复 引用 查看   

#4楼[楼主] 2007-07-24 19:49 biglee      

@补丁
重载onError方法应该不错
 回复 引用 查看   

#5楼 2007-07-24 20:13 亚历山大同志      

晕死,一夜回到解放前  回复 引用 查看   

#6楼 2007-07-24 20:21 Anders Cui      

@biglee
用Application的Error事件统一处理
也可以捕获异常
比如使用Server.GetLastError()
 回复 引用 查看   

#7楼 2007-07-24 20:28 Jeffrey Zhao      

我觉得有两个观念需要纠正一下,就是
1、Web应用有很多性能瓶颈和需要优化的地方,而这个方面其实优化的作用不大,我认为。
2、如果您在写ASP.NET应用时,可以在Global.asax里捕捉全局的exception,一般来说。
 回复 引用 查看   

#8楼 2007-07-24 20:40 海阔天空      

如果没有异常发生时try...catch...是不会影响性能的,我记得。  回复 引用 查看   

#9楼 2007-07-24 20:41 xiao_p      

@亚历山大同志
:-)

运行时异常只要统一的捕获,记录日志则可
 回复 引用 查看   

#10楼 2007-07-24 20:55 Reeezak      

try catch当然要耗资源,当初人们不是都反对在页面的后置代码中加这个吗?(当然,我个人从来都感觉这样的做法是掩耳盗铃之举)

实际上,那些exception捕获了之后又有多少需要特殊处理的?不过是为了给客户一个好看一点的界面罢了,那么直接用customerror,如果还要记录一下,就用application的onerror,别的我还真的想不出来有什么用途

此外,trycatch主要还是在栈上进行工作的,那么一个应用程序的性能受trycatch的影响又会大到哪里去?当然你来几个没完没了的递归,还是会很快就完蛋了的,其实数据库方面可优化的地方更多一些
 回复 引用 查看   

#11楼 2007-07-24 21:03 Ariel Y.      

一个try catch所耗费的资源相比连接数据库所耗费的资源简直是九牛一毛。楼主完全是因为解决一个很小的问题而引入了一个更大的问题。

对于性能这种东西,一定不要想当然,一定要用数据说话,自己测测去。

多几个try catch不是问题,问题是最好通过程序的判断避免抛出Exception。当然,数据库Down了那种Exception,连站点都歇菜了,还考虑什么性能啊。
 回复 引用 查看   

#12楼 2007-07-24 21:11 volnet(可以叫我大V)      

try catch没异常的时候哪里有什么大大的消耗等着你,只有在有异常的时候才会出现,代码中的try catch数量并不关联你的程序,数据库连接资源是多么的宝贵啊,你看看一个页面有多少次需要访问数据库啊,天哪,那你的数据库服务器先down掉了  回复 引用 查看   

#13楼 2007-07-24 21:11 chy710      

用using语句...  回复 引用 查看   

#14楼[楼主] 2007-07-24 21:11 biglee      

@Ariel Y.
我确实只是在考虑这个问题,我也是想到了这点,有时间我就去着手测一测具体的数据
 回复 引用 查看   

#15楼 2007-07-24 21:19 alonesword

嘿嘿,

1、个人感觉使用 application 中的 error 可以捕捉网站的错误,并提示一部分信息给用户,告诉他网站出错误了。然后转向到友好的页面,这样比较好。
2、LZ说的页面开始就连结数据库进行数据库是否为正常状态的方法。鄙人不是很同意。大家都知道数据库资源是很紧张的,特别是web 中,在页面中尽量少连结数据库。比如:你可以为页面的数据处理使用 Manager,只有Manager 中的读取数据的方法可以进行相关数据库操作,其他的方法都是一些对数据进行Business 处理的,这样,就可以大大减少数据库连结耗时。你可以对比一下,try...catch...finally...对于Database connection 的耗时情况,为了减少数据库连结状态而每个页面都进行数据库连结是得不偿失。如果你非的要这么做,建议使用Ajax 后来操作,否则,用户是没有耐心等待你的连结结果的。

我现在手里就有一个网页是按照LZ的方法做的,每一个页面就搞一个 DataConnection ,不管你这个页面有没有数据操作[数据有可能来自于 session 或其他的文件,xml],只要用户容许,可以打开20多个网页,你的server 就game over 了,后来发现是网页中出现了数据库连接,而且一开着连接就是 open 状态了。后来更改后,对Dataconnection 封装,然后close ,到真正需要使用的时候再Open,情况就ok了
 回复 引用   

#16楼 2007-07-24 21:26 henry[未注册用户]

即使有损耗也要看损耗的情况,如果try catch的损耗还不到一个页面解释百份之一那把时间花在这问题就真是浪费.不要小问题复杂化.
如果楼主质疑try catch的损耗用Stopwatch简单地走一下就可以了,花不了你几分钟.
 回复 引用   

#17楼 2007-07-24 21:58 hehe[未注册用户]

本末倒置了
异常本来是小概率事件,花点时间和资源来处理绝对是必要的,如果频繁发生,那恐怕就是bug了
 回复 引用   

#18楼 2007-07-24 22:12 RicCC      

几乎所有提到try catch的地方,都是讲不要使用这个机制来进行流程控制,搞得大家都对try catch怕成这个样子了  回复 引用 查看   

#19楼 2007-07-24 23:11 kiler      

想说的大家都说了,异常比较耗性能的前提是系统有错误,即时你不捕获一样的很耗性能。再说啦,你的系统的时时刻刻都在产生错误吗?不要因小失大。  回复 引用 查看   

#20楼 2007-07-24 23:15 EVO[未注册用户]

20个链接就 挂掉 不是吧,连接池使用来做什么的呢  回复 引用   

#21楼 2007-07-24 23:38 三千.℡      

该说的大家都说了,还是要用数据说话.这样想当然没有根据.
 回复 引用 查看   

#22楼 2007-07-24 23:59 jjx[未注册用户]

过犹不及,平时该怎样写代码就怎样写,如果遇到性能问题时再用 profile 分析后再优化  回复 引用   

#23楼 2007-07-25 07:59 绿蚂蚁      

因小失大了,我觉得异常机制本身还是很好的  回复 引用 查看   

#24楼 2007-07-25 08:29 金色海洋(jyk)      

如果没有异常发生时try...catch...是不会影响性能的。  回复 引用 查看   

#25楼 2007-07-25 08:45 jillzhang      

楼主主观臆断,欠缺考证
鉴定完毕,:)
 回复 引用 查看   

#26楼 2007-07-25 09:06 Anders Liu      

尽情地抛,尽情地踹,尽情地开吃。
异常就是让你用的,如果都能用if搞定,异常也就不会出现了。
 回复 引用 查看   

#27楼 2007-07-25 09:06 Zealic      

TryCache
工作于 Stack 之上
性能损耗很小
并且只有在发生异常时才会扫描调用栈,而这里才时资源消耗的关键处
因此
TryCache 的粒度越小越好
坚决不要在 Main 之类的地方捕获

为什么叫结构化异常处理,因为他提供了一种更好的错误处理方式finally。
一个cache 可能要 N个 if 才能达到同等效果,为了稍微的性能而丧失维护性,这是绝对不可取的!
 回复 引用 查看   

#28楼 2007-07-25 09:47 阿武      

全部都用IF, 代码有失优雅吧, 再说了你能保证到你的IF把所有可能出错的情况都考虑进去了吗? try catch 没什么不好的, 只是看你会不会用, 既然使用了try catch 就要有一个理由说服自己try里面的代码会出现出乎常理的错误, 比如说数据库连接中断、网络连接中断等  回复 引用 查看   

#29楼 2007-07-25 10:36 Jeffrey Zhao      

@EVO
就是因为20个连接就挂掉,所以引入连接池阿,呵呵。
 回复 引用 查看   

#30楼 2007-07-25 10:51 Anders06      

异常处理 != 错误处理 很多人都有这种相等的错误观念
有时候我也搞不懂,该用assert呢还是throw exception, 看FCL基本上都是先判断一下传进来的参数,不合格就throw的. 类库应该比较严格吧,application好像做法又不同了
 回复 引用 查看   

#31楼 2007-07-25 11:56 BlueAnson      

个人感觉能不用try catch的就不用,asp.net不是有customError设置吗,本地出错了就会显示错误,,正式发布到外网的时候就会跳到设置好的出错页面.

 回复 引用 查看   

#32楼 2007-07-25 12:07 step      

application 中的 error
不能捕捉特别严重的异常,如数据库字段长度不够
 回复 引用 查看   

#33楼 2007-07-25 15:38 4kapple      

我做的主要是中小企业的软件,我主张大量使用try catch,因为那点资源对我不算什么.
我觉得该用的时候就得用,就像goto.
 回复 引用 查看   

#34楼 2007-07-25 16:02 kevin[未注册用户]

同意alonesword的说法,每个页面都去连数据库,这个性能损失很大啊,try..catch,没有异常,不会占用你的资源的.  回复 引用   

#35楼 2007-07-25 23:01 Jonny Yu      

如果你的程序的确是因为经常出异常而导致性能问题那么,说不定你是把异常当正常逻辑来用了。
 回复 引用 查看   

#36楼 2007-07-26 09:35 镜涛      

通常try catch 捕获了异常也不会进行解决,只是能够反馈给用户友好的出错信息。而如果不用它出错之后就容易崩溃掉,特别是WIN Form程序。也不见得用它就慢,就消耗资源;不用它就快,就节省资源。总要进行测试才可以得出结果把!呵呵  回复 引用 查看   

#37楼 2007-07-26 22:06 阿牛      

我还是会选择用try catch  回复 引用 查看   

<2007年7月>
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

导航

统计

公告

姓名:大李
性别:男
家乡:遥远的北方
现住址:祖国伟大首都
工作地点:失业中
QQ:239674364
MSN:lzc850612@hotmail.com
GTalk:lzc850612@gmail.com
Email:lzc850612@gmail.com
Free Web Counter
Free Web Counter
昵称:biglee
园龄:5年8个月
粉丝:0
关注:0

搜索

 
 

常用链接

随笔分类

随笔档案

my friend's blog

最新评论

阅读排行榜

评论排行榜

推荐排行榜