2012.5.23微博热报：需求分析、性能调优
- - InfoQ cn@阿里巴巴中国在 微博中举了一个对设计花瓶的需求分析示例，引起了大家对需求分析技巧的讨论； @左耳朵耗子在 微博中表示性能调优不一定要自己使用缓存，因为许多层面已经设计了缓存机制. @阿里巴巴中国在 微博中举了一个例子：“需求方说：帮我设计一个花瓶. 小A肯定做出了花瓶，但是未必是顾客想要的.
2012.5.23微博热报：需求分析、性能调优
标签：
微博
需求分析
性能调优
| 发表时间：2012-05-23 21:18 | 作者：
出处：http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117
@阿里巴巴中国在 微博中举了一个对设计花瓶的需求分析示例，引起了大家对需求分析技巧的讨论； @左耳朵耗子在 微博中表示性能调优不一定要自己使用缓存，因为许多层面已经设计了缓存机制。
需求分析
@阿里巴巴中国在 微博中举了一个例子：“需求方说：帮我设计一个花瓶。小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编辑，从事企业级Web应用的相关工作，关注性能优化、Web技术、浏览器等领域。
相关 [微博 需求分析 性能调优] 推荐：
如何做需求分析
- - 人人都是产品经理这段时间我做了两个大项目，其中一个项目算是商业模式上和使用规范上的调整，另一个项目是之前功能的重做，为什么重做我下面会说到. 关于需求分析，我认为把需求抽象成产品功能花费的时间占到了软件开发周期的40%，产品设计到评审完的时间大概是20%，也就是说实际开发之前产品团队介入的工作占据项目的60%，在需求分析阶段我有一些个人观点.
HBase性能调优
- - 学着站在巨人的肩膀上我们经常看到一些文章吹嘘某产品如何如何快，如何如何强，而自己测试时却不如描述的一些数据. 其实原因可能在于你还不是真正理解其内部结构，对于其性能调优方法不够了解. 本文转自TaoBao的Ken Wu同学的博客，是目前看到比较完整的HBase调优文章. 原文链接：HBase性能调优. 因官方Book Performance Tuning部分章节没有按配置项进行索引，不能达到快速查阅的效果.
hbase性能调优
- - 数据库 - ITeye博客 1）、hbase.regionserver.handler.count：该设置决定了处理RPC的线程数量，默认值是10，通常可以调大，比如：150，当请求内容很大（上MB，比如大的put、使用缓存的scans）的时候，如果该值设置过大则会占用过多的内存，导致频繁的GC，或者出现OutOfMemory，因此该值不是越大越好.
Hadoop性能调优
- - 开源软件 - ITeye博客是否对任务进行profiling，调用java内置的profile功能，打出相关性能信息. 对几个map或reduce进行profiling. 非常影响速度，建议在小数据量上尝试. 1表示不reuse，-1表示无限reuse，其他数值表示每个jvm reuse次数. reuse的时候，map结束时不会释放内存.
MapReduce - 性能调优
- - CSDN博客云计算推荐文章 Hadoop为用户作业提供了多种可配置的参数，以允许用户根据作业特点调整这些参数值使作业运行效率达到最优. 对于一大批MapReduce程序，如果可以设置一个Combiner,那么对于提高作业性能是十分有帮助的. Combiner可减少Map Task中间输出的结果，从而减少各个Reduce Task的远程拷贝数据量，最终表现为Map
Task和Reduce Task执行时间缩短.
Java 性能调优
- - 编程语言 - ITeye博客1.用new关键词创建类的实例时，构造函数链中的所有构造函数都会被自动调用. 但如果一个对象实现了Cloneable接口，我们可以调用它的clone()方法. clone()方法不会调用任何类构造函数. 在使用设计模式（Design Pattern）的场合，如果用Factory模式创建对象，则改用clone()方法创建新的对象实例非常简单.
Spark性能调优
- - zzm通常我们对一个系统进行性能优化无怪乎两个步骤——性能监控和参数调整，本文主要分享的也是这两方面内容. Spark提供了一些基本的Web监控页面，对于日常监控十分有用. http://master:4040（默认端口是4040，可以通过spark.ui.port修改）可获得这些信息：（1）stages和tasks调度情况；（2）RDD大小及内存使用；（3）系统环境信息；（4）正在执行的executor信息.
需求分析中的产品定位
- Jessica - 所有文章 - UCD大社区看过《定位》最大的感受就是产品在诞生之前就决定了他是否能存活或成功. 就像走在商场中，面对玲琅满目的产品，你似乎很难找到一两款绝对同质化的大品牌：. 各式的服装，NIKE的衣服是运动的，但也不会和做户外运动的哥伦比亚冲突. 都是做化妆品，Fancl打出“无添加”没有防腐剂也收获了一群喜爱天然的用户…...
性能调优攻略
- - 酷壳 - CoolShell.cn关于性能优化这是一个比较大的话题，在《 由12306.cn谈谈网站性能技术》中我从业务和设计上说过一些可用的技术以及那些技术的优缺点，今天，想从一些技术细节上谈谈性能优化，主要是一些代码级别的技术和方法. 本文的东西是我的一些经验和知识，并不一定全对，希望大家指正和补充. 在开始这篇文章之前，大家可以移步去看一下酷壳以前发表的《 代码优化概要》，这篇文章基本上告诉你—— 要进行优化，先得找到性能瓶颈.