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

原创
10/20 09:08
阅读数 6.6K

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

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

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

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

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

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

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

加油吧,骚年!

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

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

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

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


原创不易,莫要白票,如果觉得有点用的话,请毫不留情地素质四连吧,分享、点赞、在看、留言,随你便,这将是我写作更多优质文章的最强动力!

本文分享自微信公众号 - 沉默王二(cmower)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
2
3 收藏
分享
加载中
更多评论
打赏
0 评论
3 收藏
2
分享
返回顶部
顶部