服务器做了两个优化 CPU 使用率减低 40%
1. 问题描述
大家应该注意到了最近社区访问速度有点慢,一直以为是家里 wifi 不给力覆盖范围不够,直到 @leo 喊我说服务器太慢,CPU 爆了:
上 UCloud 后台看数据比较直观:
CPU 使用率居高不下,有时候还伴随着 MySQL 爆掉的情况,如下图。当这种情况发生时,你就会发现网页请求卡住不动:
经过一番调查,定位到两个问题,下面分别讲解各自的解决方案。
问题一:话题显示时实时更新查看数
每次页面的查看,都要触发一次数据库 UPDATE 操作,当社区帖子 PV 很高时候,瓶颈就会很明显。
解决方案
核心思路是尽量少碰到数据库,利用较快的记录器来做记录。这里选择使用 Redis 的 Hash 数据类型来存储。Redis 运行在内存中,效率将会非常高。
实现逻辑:
- 按照日期分开存储
view_count
到 Redis 里,按日期命名 Hash,如:laravelchina:counter_cache_2018-06-17
; - 字段名按照命名规则
数据表_字段名_ID
,如话题表里 ID 为 1 的view_count
字段 ——topics_view_count_1
; - 设置计划任务每天凌晨将昨天的 Hash 同步到 DB 中,并删除;
问题二:未读消息 Ajax 请求太频繁
登录用户情况下,每一个浏览器打开的社区页面,每过 15 秒钟就会发送一次未读消息的 Ajax 请求,像我查阅资料时,很多时候会同时打开几十个页面:
上图这种情况每 15 秒钟就会给服务器发送几十个请求… 看着自己写的 Bug,无奈感叹:
解决方案
核心思路是不论浏览器打开了多少窗口,浏览器内的所有窗口在单位时间内(15 秒),只能发送一个请求。怎么做到呢?利用现代浏览器内置的 localStorage 功能可以很容易实现:
- JS 端使用 localStorage 在请求成功后记录
notification_requested_at
的值为Date.now()
; - 在每一次请求发送前,拿当前时间
Date.now()
减去notification_requested_at
时间; - 如果大于 15 秒,就发送请求;
- 否则放弃请求,直接读取 localStorage 里的
notification_count
; - 请求成功后将获取到未读消息数存入 localStorage 键为
notification_count
; - 每次刷新页面,JS 初始化时未读消息数存入 localStorage 键为
notification_count
。
有同学在问为啥不使用长链接,首先这里要求的实时性不需要那么高,其次,我有意保持程序架构的简单,Keep it simple and stupid ,越简单越方便维护,够用就行。
优化结果
看来又可以延迟升级服务器配置的时间了。性能优化的路漫漫,准备找个时间好好优化下社区程序,顺便看看能不能输出一些优化日记。听说 PHP 7.2 性能要好个 10%, 现在也趋于稳定,有在考虑升级下 PHP 版本。
最后问大家一个问题:你写过最愚蠢的 Bug 是啥,分享下哈?
本作品采用《CC 协议》,转载必须注明作者和本文链接
推荐文章: