BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

2012.5.23微博热报:需求分析、性能调优

| 作者 崔康 关注 0 他的粉丝 发布于 2012年5月24日. 估计阅读时间: 7 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

@阿里巴巴中国微博中举了一个对设计花瓶的需求分析示例,引起了大家对需求分析技巧的讨论;@左耳朵耗子微博中表示性能调优不一定要自己使用缓存,因为许多层面已经设计了缓存机制。

需求分析

@阿里巴巴中国微博中举了一个例子:“需求方说:帮我设计一个花瓶。小A设计师直接去做花瓶去了。小B多问了几句:多大的?什么材质的?什么时候要?预算是多少?小C则问:你要花瓶做什么的?是放鲜花还是做室内装饰用的?小A肯定做出了花瓶,但是未必是顾客想要的。小B也做了花瓶,顾客也买单了,已经合格了。但是小C则有可能让顾客惊喜。”

大家对此的看法:

刘光裕:只有抓住用户真正的需求,才能做出好产品。但不等于只有通过用户调研才能做出好产品。很多东西,真的只有放在用户面前,用户才会理解其价值。

宋安:因为小C考虑了具体的用户需求场景,具有用户体验和品牌营销的思维,而不仅是制造一个简单的产品。

chennychen:乔布斯直接做了,然后告诉客户:这就是你要的花瓶。客户惊喜,欣然买单。

JAMU時尚插畫師:但是很可笑的是很多老板只会告诉你我要一个花瓶~而且即便做到问清楚材质神马的老板各种不满意~所以这个理论现实生活中根本不可能。

loary311:小C的成功是在于了解产品的用途,然后在生产的时候尽最大可能去满足客户的这个需求,物善其用,客户有物超所值的感觉自然会感到惊喜。

innovate511:IT面向业务需求,何其相像,不仅仅是业务部门面向用户时才会碰到,任何服务性的双方都会面临这个问题。

七斗先生:非也,有时候顾客并不知道自己真正需要什么。好的产品并不是满足顾客的所有需要,而是给他们一个购买的理由。

@宋安:用户需求和需求场景的识别是销售的前提,产品和服务的本质是如何满足需求,并创造良好的用户体验。

Skydesign:客户往往很难表达他们要什么,但是他们知道他们不要什么。所以在中国很多时候,DEMO比PPT来得有效果~

李结林:如果客户对小C说“和你有关系吗?”小C该怎样回答,创新固然重要,但是要以客户的利益和需求为出发点,小B的做法,不错。在懂得了客户的需求后,在客户的可接受范围内,适当加入小C的角色是可以考虑的!

性能调优 

@左耳朵耗子微博中说:“每每一和人说到性能调优的东西,就会听到人马上说要建个cache或是用个hash table 缓存什么的,我总是觉得并不一定啊。因为cache这个东西到处都有啊,从CPU的L1 L2到RAM都有cache,OS读文件运行程序也有cache,RDBMS也有cache,语言层面JVM里也有cache,网卡上也有cache……,有时候真没必要自己建了。”

大家对此展开了讨论:

jametong:在很多人眼里,速度不行,那就上个缓存吧!至于缓存到底是什么?该如何利用各种不同的缓存,他所处理的具体业务场景是否需要缓存?那则是另一个问题!

压力很大同志:缓存也算是一种空间换时间的方法嘛,有的结果明明可以反复用的就存起来。业务逻辑部分能得到的为什么非要去RDBMS去走一遭,再说细点CPU的L1、L2也没法缓存业务逻辑需要的数据,不是在一个级别上的东西,要是指着CPU缓存了、IO缓存了、RDBMS缓存了,就反正他们都缓存了,我就不管了,这跟耍流氓无区别。

kylemick:如果单纯IO角度,应该是要的吧…瓶颈点在那里,不然也不会在这么多层面做了这么多Cache。至于算法调优,都是根据实际情况吧,没有具体情况,调优岂不是无敌了?

steedhorse:我觉得所有的动态规划算法都与Cache机制异曲同工。不过现实中我也对一碰到性能调优就想Cache的做法存有疑虑。经典线性规划问题可以用现成算法。其他问题也常可以通过算法和数据结构的改进来减少重复计算。

左耳朵耗子:我这里说的“有时候不需要”。举个例子,某应用有读很多小图片,但又不是很多,比如25万个小图片,大约不到1GB,于是想做一个cache把图片预读到内存以减小磁盘I/O,但是OS的内存管理已经帮你干了,真的没必要自己再干了。

吴尔平-andy:不支持这种说话,换个顺序理解一下,为什么CPU需要L1、L2、L3,为什么有了CPU的这几级还要文件Cache, 要db的Cache。就知道为什么有些应用需要有应用级的Cache。

校园猫:如果用OS的cache,需要从内核空间拷贝到用户空间,如果用DBMS的cache,要从数据库进程空间拷贝到用户进程空间,如果对这些时间开销可以容忍,当然可以不需要自己建cache,如果不能容忍,那还得自己建,另外cache的淘汰算法也不能控制,除非完全能装下不考虑淘汰。

steedhorse:这个话题好像说乱了。原因是楼主前半句跟哈希表相提并论的cache指的是“计算结果缓存”,比如很多人都会不太严格地讲“把运算结果cache起来”,这是cache的一种不太正宗的用法。而后半句的cache指的是存储结构上的cache,这个是cache一词的正宗本义。前后两个cache在含义上不太一致,导致了各说各的。

Robin圈:性能问题之所以难解决,通常是我们错过了第一解决时间,搞的自己都不知道问题再哪里了。所以如果性能成为了关键指标,那么就应该集成到CI中,如果要求是1s,那么超过了就该给个failed。

jametong: 瓶颈更多是基于设计、业务来定位的,深入业务、系统,找到有共享资源的点(L1/L2缓存,CPU调度、业务热点账户,流程设计的热点),通过测试来寻找瓶颈是代价非常高昂的方式,测试很多时候只是用来验证,而不是寻找!没有针对性的优化,没有经过测试找到瓶颈。

一线天色天宇星辰:往往测试一把,解决影响性能的最主要因素,就能解决问题了,十全十美的设计是不可能的,把可能遇到的性能问题都测试一把,挑主要的解决掉,否则过度设计会搞死自己的。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

需求分析 by 王 明军

关于需求分析,如果是做产品,那就在一个较大的范围做调研,用户真的不知道自己要什么,需要你去发现,什么才是用户需要的,乔布斯就是个很好的例子,如果是做应用开发,首先了解清楚当前需求,然后在基本需求上发挥自己的想象力,结合实际,做出不只让用户满足,并且能让用户在使用是有更多的惊喜,这就成功了。而不是让用户体验到了需要的,但体验很差,那就失败了。

性能调优 by Criss Chan

性能调优是一个非常泛泛的词。涉及到的不应定就是缓存,也离不开缓存。每个地方都有缓存,但是如何能够让全部部件通过缓存平滑运行,没有一个处在瓶颈之上。这才是关键

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT