起因

前两个月某朋友要做一个项目,本着快速上线推广的目的,直接购买了某公司的源码并让卖家部署上线。看到源码后,我直接对朋友说:算是被小坑了,这个源码质量有点差,用户数起来后可能会有比较严重的性能问题。

做出这样的评价,我是有依据的:

  1. 作为近乎实时应用,核心代码用PHP编写,通过数据库表记录控制许多场景的并发和重复请求;
  2. PHP开发不是问题,但对方工程师似乎不知道有CLI模式,而是通过计划任务(crontab)达到程序不停运转,于是乎浩浩荡荡几十条curl计划任务每分钟执行;
  3. 代码中有不少 class1.php, class1-1.php这样复制备份的文件,一眼看过去很难知晓其存在目的;
  4. 存在不少for循环读取数据库的代码,命名规则混乱。

当然,能赚钱的代码才是好代码(对方就通过这些代码赚钱了),我也没多去纠结。最初的想法是,4核8G的配置,跑1万个客户应该很难,跑5000就可以了。

转折

就在这周,忽然频繁接到 阿里云 的报警短信和邮件,说CPU占用过高。心想市场推广很顺利,用户大增吗?一问朋友,才不到300个用户!

阿里云报警邮件

这时才意识到,这套代码实际表现比我想想中的更差,有严重的性能问题。按照这个资源消耗速度,升级硬件是无底洞,性能优化才是正途。

性能优化

拿到代码两个月了,闲暇时间偶尔会看一下,已经大体知道其结构和主要功能。现在出现了严重性能问题,是时候尝试做一些性能优化了。

鉴于几十个计划任务不停运行,其不断驱动系统运转,因此计划任务的相关功能是最先被了解的。根据自己的理解,首先暂停了二十多个已经不需要的计划任务。暂停无用计划任务后,系统总体CPU使用率下降到了60%多,烦人的提醒短信和邮件终于消停了。等待了一天,朋友也没有反馈有功能受影响,说明思路和出手点都正确。

但是200多个用户就这么消耗资源,一定还有什么地方不对劲。今天有空又登录服务器,执行top命令,发现MySQL进程一直占据200%多的CPU资源。看过源码的我知道MySQL占用高是有原因的并且是可能的,但还是想看看为什么这么耗资源。

登录MySQL服务器,查看是否开启了slow log:show variables like '%slow%';,发现开启了慢查询日志:

mysql查询慢日志配置
mysql查询慢日志配置

接着查看日志,查到某条sql语句一直出现在日志中:

mysql慢查询日志
mysql慢查询日志

可以看到,执行这条sql语句扫描了38万多行记录。语句涉及到的两张表一张有600多条记录,另一张4万多条记录,相当于全表扫描了4万多的表好几次,怪不得特别慢。

接着检查两张表的索引,除了自增id作为主键外,没有创建其他索引。使用explain执行语句,显示没有使用任何索引:

mysql explain执行语句

接下来,在两张表上分别就查询条件的uid、session_id列上创建索引。索引创建完成后,肉眼可见的CPU占用率和系统负载都降下来了。再次使用explain执行查询语句,索引信息已经用上了,扫描行数大大减少:

优化后的explain结果
优化后的explain结果

经过上面的优化,目前应用的总体CPU占用率在5%左右,MySQL的CPU占用率大约为15%,系统负载从4降到了0.3。终于暂时不用担心性能问题了,即使服务器配置降到1核CPU也能撑得住。

2021.11.06更新:进一步查看代码并结合日志,创建索引和修改部分查询语句,CPU占用率降到6%左右,终于暂时不用担心性能问题了

总结

工程师在开发工程中,不仅要写出“能用”的代码,更要写出“好用”的代码。本例中通过创建两个索引就能大幅提升系统性能,便是让代码从“能用”转到“好用”。

本文提到的性能优化偏运维,代码中的性能优化暂时还未触碰。但一个总体的原则是不会错的:多使用缓存,尽可能的减少慢IO设备的同步读取。

参考

1. 记一次C++程序优化经历

2. WordPress性能优化