Remember: 我们是做产品的,不是搞学术研究的 & 用事实说话,不要臆断

近来发现,有很多同事在设计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。

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

时间: 2024-11-05 21:37:25

Remember: 我们是做产品的,不是搞学术研究的 & 用事实说话,不要臆断的相关文章

艾伟:Remember: 我们是做产品的,不是搞学术研究的 & 用事实说话,不要臆断

近来发现,有很多同事在设计Asp.Net Application时,选择用字符串拼Html文本而不用GridView等控件,原因居然是"Asp.Net太慢".看来有必要再次明确一个本质问题:我们是做产品的,不是搞学术研究的:同时要强调一个习惯:要用事实去证明你的猜测,而不要臆断. 一.Remember:我们是做产品的,不是搞学术研究的 直接贴一个前阵子的一封邮件,"全在邮件里面了": 发件人:  发送时间: 收件人: 主题: 答复: 关于WebService的性能损

互联网产品设计思想:给别人做产品

上周五的5G白话上,阿北说,工程师必须从给自己做产品的惯性中走出来,变成给别人做产品.阿北自己完成这个转变,用了大约两年时间.也就是说,到 2007年,阿北清醒地意识到,豆瓣不是给自己做的,用户怎么使用豆瓣也不再是工程师能够决定的. 给自己做产品,是一个很好的开始.尤其对工程师来说,你自己的需要,你自己的不满,你自己的渴望,只有你自己最清楚,满足了自己,很可能就会同时满足一批跟自己类似的人的需要.这让一个新产品,很容易聚拢第一批用户.很多成功的产品,从iPhone到Twitter,都是这么开始的

从PD、UED、产品本身和运营角度谈如何做产品

曾经,"非设计师谈设计"系列前两季得到了很多朋友的关注和认可,很多人特别期望看到新的一篇,时隔2年,征得胡斐同意,他携重磅文章再次出击,结合自己在淘宝积累出的经历和感悟,对产品方方面面有了更宏观的认识.本篇共分4个部分,从PD.UED.产品本身和运营角度谈起如何做产品,整个文章一气呵成,让我读起来有种畅快淋漓的感觉,希望读者您也能喜欢,欢迎评论. (1)要栓在一起的PD 我在淘宝做了几年运营,观察大大小小的产品设计.活动策划,发现运营和PD*,和UED*在沟通上总是会出现各种问题.好的

如何利用seo技巧做产品站

自从6月28日后,百度算法调整一再改变,seo大师zac接受某网络采访时,说道:"往后的seo会越来越淡化技巧,越来越重视内容."此言一出再度雪上加霜,seor们不单单要忍受K站降权等等问题,还要把心思全放在无聊的内容建设上(内容的建设往往是需要时间的不断沉淀).事实上,在以前的格局里,多数的seor们总是把心思放在技巧上,例如面包屑导航中加入关键词.底部次导航建设,建设视频外链.分类外链等等.当一个引领白帽seo最尖端的人说这些将越来越被搜索引擎淡化时(我们总会理解成seo技巧将没有

林夕阁采访:秦剑谈个人SEO如何转型做产品

  秦剑,毕业于广东医学院,2007年开始接触网站. 实践派SEO,通过实践去分析现象,在大量的实践中积累了丰富的经验,对SEO有自己独到的见解.曾获09年站长网(ADMIN5)举办的SEO大赛(谷百优)百度第一名.GOOGLE第二名,擅长优化企业网站的百度排名,同时对百度竞价.Google Adwords和网站转换率有着实战经验.08年开始接单做SEO,09年底在某公司就职工作至10年10月,而后辞职一直在家一边负责企业SEO与个人网赚,10年接触淘宝客-- 采访记录如下:(此文字版本有所省略

QQ空间:做产品,果然难于上青天

互联网"精英人群"中,用QQ空间的人貌似很少. 小米与QQ空间合作发布红米手机,半小时内预约量冲破100万,这让伙伴们惊呆了:它竟然会有如此惊人的影响力.QQ空间已经默默成为了国内第一大社交网络平台.根据社会化分享工具提供商JiaThis的统计,QQ空间的分享量长期排在榜首,只是近期偶尔会与新浪微博交错上升. 不谈腾讯大战略,也不谈业界八卦,仅从产品角度来分析,2005年诞生的QQ空间走过了中国互联网社交领域的几次大转折,它的竞争对手换了一茬又一茬,新浪博客.51.校内网(人人网前身)

尚雯婕也要做电商,做艺人用做产品思路

冠军光环转瞬即逝,接下来是长达几年的焦虑期:市场定位不准,出唱片不赚钱.高额投资收益惨淡,尚雯婕几乎要被华谊放弃.最惨时,尚雯婕给华谊负责商务.后来成为8年合伙人的聂心远打电话,两个人边聊边哭. 早期围绕尚雯婕的全是过于夸张的造型带来的质疑.但是几年过去,尚雯婕不一样了,不仅通过<我是歌手>逆袭,还贴上鲜明电子乐及个性时尚标签,她以女王姿态重回主流公众视野. 帮尚雯婕重新赢回市场的,除了证明自己的强烈意愿,更重要的是背后团队运营:用做产品的思路去包装一个艺人. 所以你看到的尚雯婕频繁上时尚杂志

请教:做产品的公司,项目经理到底该不该负责产品的策划

问题描述 在做产品的公司里面,公司想要一个业务平台,但是只有高层领导很粗糙的想法,就再没有明确的需求了.项目经理该不该负责自己定义各种产品的功能.数据.流程等需求,我感觉产品要做成什么样应该由产品策划人员或者产品经理来负责啊,项目经理应该只负责如何去实现.如果要做成什么样子都由项目经理来负责,那项目经理不也肩负产品经理职能了? 问题补充:高级java工程师 写道 解决方案 在小的公司一般项目经理,需求.代码.开会.架构.流程图.数据库结构图.类关系图.都要搞,一般公司有自己的架构,如果有,在平台

我是去小公司做java开发,还是去大公司做产品运营?

问题描述 今年跨考计算机研究生失败,然后开始找工作.现在收到offer了开始纠结,是去大公司做产品运营还是去小公司做java开发呢? 解决方案 解决方案二:看你的描述好像也没做过什么开发,那还是运营去吧解决方案三:去大公司做运营吧解决方案四:做产品,主要是想象力运营,主要是计算机硬件相关方面的只是开发就不说了解决方案五:新人还是做开发的好运营这个事,基本就是一网管,没啥意思解决方案六:说的好听是运营,说难听是网管解决方案七:folllowyourheart做爱做的事情解决方案八:引用5楼CKRG