对性能调优标准一无所知？

前几天，和一个同学瞎聊，他说，“我们公司的系统从来都没有经过性能调优，集成测试没问题后就上线了，上线后也几乎没出现过性能问题。”

我当时没回他。因为没遇到性能问题不代表程序不存在性能问题，只能说明系统的访问量有点小。有印象吧？每次明星爆出个大瓜，微博就挂了，那就是因为短时间内访问量暴增后，扛不住压力，出现了性能瓶颈。

大部分的性能问题都是由于访问量过大导致的，我记得汪峰在京东做过一次直播，那画面卡成狗，几乎没法下单，画面都出不来。因为京东之前没做过直播，没遇到这么大访问量，估计那次活动结束后，直播方面的开发没少挨批。

还有一部分性能问题是随着时间积累爆发的，程序在服务器上运行一段时间后就要重启，否则某个时间节点内存就突然爆掉了。反正我司一些项目就遇到过这方面的尴尬，一开始的解决方案就是写个脚本，在夜深人静的时候，偷偷地重启释放一下内存。

在性能方面要求最高的我认为就是 12306，搞不好是要被全国人民骂街的。以前在苏州的时候，不论是不是节假日，每次坐火车回洛阳，或者从洛阳去苏州，都感觉同伴好多啊，怎么这么多人坐火车，不是南下就是北上，不是东进就是西出。遇到春运的时候，12306 承载的压力可想而知有多大，秒杀活动压根没法和它相提并论。

如果有小伙伴为 12306 工作过，那可以吹一辈子的牛逼了，你比在淘宝双十一工作过的小伙伴牛逼一万倍（嗯，我先替你吹一波，据说 12306 的高峰访问是 10 亿 PV，非常 BT）。

知道了性能调优的重要性后，我来问问小伙伴们，什么时候介入性能调优会比较好？

如果你的回答是“越早越好”，那显然是错误的答案。

我在之前的文章中提到过软件开发的一条原则，就是“ Done is better than perfect ”，因为“ perfect is never done ”。性能调优是一项持久战，很早就开始介入，并不是一件好事。

你想啊，系统第一时间上线才是最重要的，不然你一边想着性能调优，一边疲于开发进度，可能两者都做不好，反而拖累了系统研发的进度。等你系统上线了，可能用户已经被别的系统抢走了，你永远都没有性能调优的机会了。

不要总想着把所有的功能做完善，做完美后再上线，应该在产品具有一定的雏形后就立即上线试错，根据用户的反馈，根据市场的需求再去考量是否追加一些其他的功能或者优化。

那我再来问问小伙伴，哪些因素会成为系统的性能瓶颈呢？闭上眼睛，转个圈，想一想。

• 数据库：几乎所有的系统都会用到数据库，大量的数据库读写操作会严重影响到系统的性能，所以数据库缓存技术 Redis 变得越来越重要。另外，系统运行时间久了之后，数据量就会变得非常大，不仅需要在 SQL 上做很多优化，还要在分库分表上下足功夫。

• 网络：如果你家的网速很慢，那就要去问问运营商，你家的带宽多少。或者，至少检查一下，你家的网线是百兆的还是千兆的，虽然网线都很短，短到只有猫到路由器那么一小节。网络带宽如果太小的话，就意味着数据传输得很慢，就像跑车到市区，搞不好还没有自行车快。

• 磁盘：我家里的台式机都换成了固态硬盘，换了之后的速度就比之前普通硬盘的快很多。多说一点，数据库的读写操作就是磁盘 I/O，而 Redis 之所以快，就是因为 Redis 操作的是内存，但 Redis 牛逼的一点在于它不仅可以做缓存，还可以将数据持久化到磁盘。

• 内存：内存的读写速度比磁盘快得多，但空间远没有磁盘那么大，一般家用的计算机内存在 16G 已经是很高的配置了。众所周知，Java 程序是通过 JVM 分配内存的，创建的对象都放在堆内存上，操作起来就很快，但如果代码写得有问题的话，就很容易造成内存溢出。

• CPU：CPU 的计算速度快到超出人的想象，所以阿尔法狗可以轻松地打败柯洁。如果，我真的是说如果啊，放在 CPU 还是奔腾的年代，柯洁还是可以轻松打败阿尔法狗的。如果程序涉及到大量的上下文切换，或者造成 JVM 频繁的 GC，就很容易长时间占用 CPU，导致出现性能问题。

在实际的工作当中，小伙伴们也可以按照上面的顺序进行性能调优。一开始，不要盲目对内存和 CPU 下手，这个难度有点大，并且效果不明显；搞不好，还会影响到整个系统的使用。先从数据库、网络和磁盘着手优化，很容易看到效果，并且不容易出错。

最后一个问题，小伙伴们知道系统的性能指标吗？

1）响应时间

很多年以前，我干过一件很蠢的事。公司有一台闲置的云服务器，是 Windows Server 版的，刚好有一客户想体验我司的系统，我就没想那么多，把系统部署到了这台云服务器上。

结果呢？

首页打开的速度超级慢，慢到需要将近一分钟的时间。不仅客户的下巴惊掉了，我自己的也掉了。

为了挽回颜面，我对首页相关的后端和前端做了很多优化，后端刻意使用了缓存技术，减少了 SQL 语句的查询；前端压缩了 JavaScript 和 CSS，减少了请求数，甚至更换了 CDN，使用了图片懒加载，但收效甚微。

最后静下心来想了想，同样的代码，部署到 Linux 环境下的那个系统就很快，就算是第一次打开首页需要加载资源，响应时间仍然短到无法感知。于是就把 Windows Server 重装成了 CentOS，效果立竿见影，响应时间短到离谱。

那，一个系统的性能好不好，响应时间（指系统对请求作出响应的时间，比如用户打开首页）就是最明显的一个直观上的指标。对于游戏来说，响应时间小于 100 毫秒还算不错，响应时间在 1 秒左右勉强接受，如果响应时间达到 3 秒就没法玩了。

2）吞吐量

吞吐量（Transaction Per Second）是指系统在单位时间内处理事务的数量，一个事务可能包含多次请求，它反映出系统承受的压力。

需要注意的是，TPS 和 QPS 是不一样的，后者指的是单位时间内请求的数量，当用户的操作只包含一个请求接口时，TPS 和 QPS 没有区别。

吞吐量可以细分为网络吞吐量和磁盘吞吐量。前者是指在某个时刻，在网络中的两个节点之间，提供给网络应用的剩余带宽。即在没有帧丢失的情况下，设备能够接受的最大速率。后者是指单位时间内系统能处理的 I/O 请求数量，I/O 请求通常为读或写数据操作请求，关注的是随机读写性能。

最后来简单总结一下。性能调优非常重要，不仅用户体验好，系统稳定，更能体现出真正优秀的编码水平。我相信所有的小伙伴都能写出跑的通的代码，但至于痛不痛快，就需要在性能方面有所研究了。

换句话说，如果你跳槽到一家公司，恰好解决了原有系统的性能瓶颈，那不得了啊，兄弟，你立马就得到公司重用了！

加油吧，骚年！

------------------

公众号：沉默王二
掘金：沉默王二
这是一枚沉默但有趣的程序员，你知道，他的文章风趣幽默，读起来就好像花钱一样爽快。

长按下图二维码关注，你将感受到一个有趣的灵魂， 且每篇文章都有干货。