同学信誓旦旦地说,我司的系统从来不做性能调优!

2020/10/28

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

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

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

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

在性能方面要求最高的我认为就是 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 请求通常为读或写数据操作请求,关注的是随机读写性能。

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

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

加油吧,骚年!

PS:如果你想学习性能调优方面的知识,我推荐给你一些书单:

《代码整洁之道》,从代码层面进行优化,干净的代码,既在质量上较为可靠,也为后期维护、升级奠定了良好的基础。

《码出高效:Java 开发手册》,对 Java 规约的来龙去脉进行了全面而彻底的内容梳理,深入浅出地将计算机基础、面向对象思想、JVM 探源、数据结构与集合、并发与多线程、单元测试等知识客观、立体地呈现出来,教你从根上写出高效的 Java 代码。

《重构,改善既有代码的设计》,重构,就是在不改变外部行为的前提下,有条不紊地改善代码。

《Effective Java》,揭示了应该做什么,不应该做什么,从而写出清晰、健壮和高效的代码。

《Java 性能优化》、《MySQL 性能优化》、《Tomcat 性能优化》等等就是从实战的角度,优化应用程序的性能。

PPS:推荐一个 GitHub 仓库吧,里面有部分性能优化方面的电子书,需要的自取:

https://github.com/itwanger/JavaBooks

日常求个三连,谢谢你勤劳的手指,嘿嘿。

(转载本站文章请注明作者和出处 沉默王二

Show Disqus Comments

Post Directory