博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

近来发现,有很多同事在设计Asp.Net Application时,选择用字符串拼Html文本而不用GridView等控件,原因居然是“Asp.Net太慢”。看来有必要再次明确一个本质问题:我们是做产品的,不是搞学术研究的;同时要强调一个习惯:要用事实去证明你的猜测,而不要臆断。

一、Remember:我们是做产品的,不是搞学术研究的

直接贴一个前阵子的一封邮件,“全在邮件里面了”:

发件人: 
发送时间:
收件人:
主题: 答复: 关于WebService的性能损失


这个问题里面,缺少对用户场景的描述。

 
我认为,我们实际应该关心的并不是这两种方式的性能究竟差别有几倍,而是他们是否会对用户、对业务产生影响。

 
在这个例子里面,1500次的访问,WebService多出了5000毫秒,平均每次访问多出了3ms。那么我有以下几个问题:
1、当用户执行一次操作的时候,会调用几次Web Service,从而会多出多少毫秒?
2、多出的这些时间,是不是我们必须省下来,还是在允许接受的范围内、可以忽略不计?
3、如果用户的一次操作确实需要继续节省时间,是通过改接口方式更好更有效,还是通过其他方式(比如使用缓存、禁用ViewState、局部刷新等)更好更有效?

 
我觉得只有把这些用户场景描述出来,才好决策。 只要放在正确、合适的环境之中,任何一个方法都有可能是好的方法。 

 

我认为一个优秀的软件开发人员必须对程序的性能保持敏感。实际在.Net中,如果传递的数据量比较大,Web Service与Odbc方式的性能差距远不止3倍,另外使用反射与直接访问的方式相比性能差别可能超过百倍,使用属性与使用字段的方式相比性能也有几倍的差距。

但同时,我们不能局限在这些“倍数”中,要更多的关注这些差距所造成的最终影响,而不能单纯的从性能差距的倍数去判断是否使用某个技术。

就以差距明显的反射来说。如果是直接访问字段,只要执行几条cpu指令就够了;但如果使用反射,则可能需要执行几百条cpu指令。他们的性能差距很明显。但是,对于目前主频动辄几个G的cpu来说,这几百条指令是我们不能接受的么?即便用户的一次操作会触发成百上千次反射、一共多执行数万条cpu指令,转换成CPU时间也只是以微秒计。

反而是网络传输、磁盘IO这些影响性能的大头,也许将这些环节的性能提高10%,就会对用户或者业务产生明显的改善了。

 

 

发件人: 
发送时间:
收件人:
主题: 答复: 关于WebService的性能损失

 

请架构的同事一起评审一下吧

 

发件人:
发送时间:
收件人:
主题: 关于WebService的性能损失

 

写了个简单的测试,

访问同一个数据库表,访问1500次,一个直接通过Odbc访问,一个通过WebService封装转发一遍,

发现使用WebService后,花费的时间大约是直接访问的3倍左右

测试的数据如下,时间单位为ms

 

直接访问数据库时间:
2718.75
通过WebService访问数据库时间:
7750

 

直接访问数据库时间:
2656.25
通过WebService访问数据库时间:
7703.125


直接访问数据库时间:
2750
通过WebService访问数据库时间:
7656.25
 

鉴于这个性能损失比较大,ADS访问配置库时还是直接访问数据库吧,只是把对配置库的访问放到一个单独的DLL中,避免混到一起就是。

 

上面的这个例子很明显的说明了做产品与做学术研究的差别。可以说原来的同事在做决策的时候出发点没有放在业务上,过多的关注了性能的差距,而没有关注这些差距会对业务造成的影响。

二、Remember:要用事实去证明你的猜测,而不要臆断

这两天与另外一个Team的同事合作。某个页面上要求用表格显示一组统计数据。下面是一段对话:

:我们用GridView还是直接拼Html文本?

:(很疑惑,赶紧回顾了一下需求,发现没有比如嵌套表格之类的什么特殊格式)有现成的控件为什么还要拼Html文本呢?

:GridView很慢,会影响性能。

:#_#

 

类似的对话我听过不止一个人说过。

老实讲,能推断出这个理论的,一般都不是那种一只脚刚踏进Asp.Net大门的新手,估计他们已经明白了Asp.Net是怎样将aspx页面及对应的代码最终变成发往客户端的Html文本的。

但可惜的是,他们缺少了一个很重要的精神:就是上面邮件中那位同事“用事实去检验推论”的习惯。上面邮件中的同事用事实去验证了自己的推断,而提出GridView会影响性能的同学估计绝大多数都没有动手去写一段代码测试一下,虽然测试的代码很简单。

当然,我们都没有那么死板,考虑到验证结论所需要额外消耗时间,我们需要用“投入产出比”去判断我们所下的推论到底要不要动手去验证一下。如果是一个影响很小的推论,不去验证也就算了,让经验决定;但如果是大的决定,比如上面邮件中的问题涉及到了系统架构,以及上面对话中如果抛弃Gridview,系统中众多的表格需求将会消耗很多额外的时间,这些问题就必须慎重,一定不能仅仅靠猜测就去下一个如此重要的结论。

事实上,从性能上来讲使用GridView并不会增加多少Cpu耗时。一般的表格使用GridView与直接拼Html几乎没有性能差别。需要注意的是,当GridView绑定的数据很多,比如几百上千行,页面可能会慢。但必须了解这是因为http协议在传输文本时导致的页面慢,而不是因为使用了WebControl而没有直接拼Html。

 

总之,作为一个优秀的开发人员,必须对性能保持敏感,但同时更重要的是:一定要弄清楚并关注这些性能问题对业务、对产品所可能造成的影响。