性能项目到底要不要调优

上次写了《》之后，又引发了群里的新一轮讨论。总结如下：

1. 昨天他们说的都不是说性能测试工程师不该有性能分析定位瓶颈甚至调优的能力；而是觉得性能测试工程师本来就应该具备这种能力，不然就被叫成学徒，而不是工程师。
2. 当前性能市场的生态是学徒多，而工程师少。

很高兴他们终于回到了我的问题本身。

解决了这个共识之后，就要面对下一个问题了。

@All

大家觉得不懂性能的人，对性能有哪些误解和误导？像老板、架构师、开发、运维啥的。

在你们的工作中，有遇到过这些人对性能产生影响的吗？

再翻回之前的聊天记录。整理如下：

1. A: 只要硬件服务器 够好 性能就没问题 ，我遇到过。B: 我也常这样说。
2. 我见过的性能问题，如果需要及时解决，最后都是堆机器，重启解决的。
3. 让我对比性能测试环境和生产环境的差异，tps做换算。
4. 除了老版本jdk，我真觉得现在架构下还没硬件搞不定的事情，除了极少数特例。

接着我又问：对一个系统来说，如果只能支持100tps。最后堆了1000台机器，支持了100000tps。 这也叫硬件搞得定的事情？

所以，你们做性能的时候，都是说，这一个实例100tps。要支持1000，就上10台机器吧。 是这样的吗？

假设一台机器 一万。所以就加12台。就是12万呗。

如果优化了用2台，就可以。是不是2万就解决。

这样的优化，你们做不做？！

讨论摘要：

1. 要看企业的规模和程度....，比如中大型企业, 利润率高的企业，堆硬件比优化程序要靠谱多了...。比如IO不行, 那就上SSD嘛, 先能应付一下当前的需求。
2. 干嘛非要一秒解决。
3. 堆硬件立竿见影，优化则不是。
4. ssd是王道，内存数据库那iops刚刚的。
5. 其实就是个性价比的事情，算不清楚上硬件。
6. 代码架构层面 性能问题好改就改，不好改 堆机器
7. 阿里的服务器大多数资源占用率也没上5%
8. 代码架构层面 性能问题好改就改，不好改 堆机器
9. 从质量管理的角度，性能在于设计，二不在于优化。
10. @高楼 凡事要看领导怎么想的，领导要混水摸鱼，做得越好越不行。这个社会如此喧嚣，真相何其稀少。
11. 你说的性能优化 问题，我觉得要看 项目处于的阶段，没有上线的时候或者bug fix阶段，当然从代码和架构层面 优化比较好。如果在应急时候，基本就以快速解决问题 有导向了
12. 一些系统都运行好几代了，开发都换几波了，架构，底层代码现在保持能用，但不是最优。这种情况一般没人感动，牵一发而动全身，一旦改塌了……
13. 如果能优化，修改时间短，不带出其他bug，当然做。但是很多性能测试发现了，各种改无果，时间废了，kpi没上去。堆机器就搞定了，为啥不堆机器？
14. 测试本来就抬杠。（这句话是因为我中间问了一句：你们都是来抬扛的吗？）
15. @高楼 我这基本都这样。提了方案 也没法改，直接加机器解决，线上800台的优化下估计可以降到300到350，但是没人改。线上跑了好几年了 然后收入大头在这项目里 错不起。一错公司就完犊子了。因为错不起 错了公司就没了。
16. 很多，你优化了那么多人失业了。你还想混么，你可以提出问题，改不改不是本身问题那么简单。

总体来看，这些讨论集中在如下几点：

1. 如果性能问题好改，就改，不好改就堆机器。
   
2. 如果是积重难返的性能问题，优化在承担着巨大的风险，最好是维护现状。
3. 性价比高，就调优；否则不调优。
4. 看领导是不是混日子的，不然就会要求调优。
5. 把系统优化好了会导致别人失业。（这个观点就.....）

为什么会有这种讨论呢？前天有人问了我一个问题。大概描述如下：

昨天做压测，我们老板坚持3000线程并发，而系统最大只能支持2000线程并发，用3000线程并发导致响应时间超长，tps反而下降。

可能在很多的项目中，我们都有过这样的经历，觉得做为性能测试工程师的我们，具有了性能分析调优的能力，希望把这种能力体现到项目中去。

而总是有一些其他的原因导致我们的价值得不到体现。

或者总有一些看似无理的性能要求。但是对

从工作这些年的经历来说，我在性能项目中一直秉承着一个观点。性能测试的价值体现就是：

1. 找出系统瓶颈。
2. 对比优化前后容量的增加。
3. 对比优化前后成本的降低。
   

听起来似乎是显然的事情，但是在当前的性能市场中却没几个项目中做到了这几个层面？只能说很少。

有很多人说性能测试，其实不是性能容量的保证。

因为性能是架构设计出来的。关于这一点，我是有一半认同度的。

系统的整体容量规划，肯定是从一开始就要考虑的。而对一个发展迅速的企业来说，可能一开始都想不到容量应该如何规划。所以，还有另一个说法：

性能容量是演进而来的。 这个在具体的企业中，相信很多人都有感慨。因为企业的发展本来就应该是这样的，系统的发展本来也应该是这样的。

在不断的发展壮大之中，慢慢的把系统整理得更有条理。

而测试在这个过程中，其实是系统容量的验证员。

而这个验证员也照样是比较重要的工作，只是对能力上的要求就不用那么高了。因为这之前已经有人做了大量的工作。

鉴于此，对性能项目分为如下几类：

1. 新系统性能测试类：这样的项目一般都会要求测试出系统的最大容量，不然上线心里没底。
2. 旧系统新版本性能测试类：这样的项目一般都是和旧版本对比，只要性能不下降就可以根据历史数据推算容量。这样的对调优要求一般都不大。
3. 新系统性能测试优化类：这类的系统不仅要测试出最大容量，还有调优到最好的需求。

对性能团队的职责定位有如下几种：

1. 性能验证：针对给定的指标，只做性能验证。第三方测试机构基本上都是这样做的。
   
2. 性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及到调优。
3. 性能测试+分析调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态。

为什么要这样划分呢？这里会有一个组合关系。

当只能做性能验证的团队遇到旧系统新版本性能测试类和新系统性能测试优化类项目，那就会被人BS死。所以这样的团队只能做的是新系统性能测试类项目。

当做性能测试的团队，遇到需要新系统性能测试优化类项目，照样被人BS死。这样的团队能做前两种项目。

而只有第三个团队才能做第三种项目。

这样看起来就一目了然了吧。

项目需要不需要调优，不是来自于团队的能力，而是看项目的需要，这一点是肯定的。

当项目有需要，而性能团队做不了时，你只能被BS。

当团队没需要，而性能团队非要舔着脸体现能力，那就是自负了。