记一次WEB服务器性能优化

记一次WEB服务器性能优化

上个周末，自己做的一个业务后端，因为流量“过大”导致大部分请求在正常时间内都无法完成响应，故障持续了1个小时，中途只能调低nginx的连接上限，让部分人能够访问。

这个业务后端上线一个多月，那一天的流量大约占之前所有流量的1/3，而且集中在那么几个小时内，QPS压力应该是平时的几十倍，所以没抗住…

不管怎样，这是自己的锅，在实现这个业务后端的时候没有谨慎的考虑性能问题，所以当高峰流量过后就开始分析问题以给性能优化提供帮助，也为下次的流量高峰做准备。

业务后端概述

这个业务后端主要由Nginx、PM2、Node.js、MySQL、Redis、OSS组成，下面分别描述一下它们在系统中扮演的角色：

• Nginx

除了后台管理系统的静态文件，业务本身的静态文件都是放在OSS上，所以Nginx在这里的作用只是作为反向代理

• PM2

Node.js的进程管理，使用默认配置，没有其他插件

• Node.js

没有使用WEB框架，主要就是业务实现，合计约100个接口

• MySQL

所有数据都在MySQL中，整个系统一共用到约30张表，表的数据量都还不大，最大的一张表约40W条记录

• Redis

Redis在未优化之前，主要用来存session，以及之前一篇文章说讲述的的队列数据

• OSS

静态资源都存放在阿里云的OSS上，这部分流量完全不经过机器，跟系统负载没有关系

以上系统组成中，MySQL用的阿里云RDS服务（基础版1核1G），其他除OSS外都部署在同一台阿里云ECS（1核2G）上。

整个后端系统大约花2-3周做出来的，没有压力测试，没有性能指标等，也没有特意去优化，并且自己心中知道有部分逻辑不合理，有量的时候应该会出问题。

分析现状

问题过后，要做的第一件事是分析现状，主要包括以下内容：

• 故障原因
• 量化本次高峰流量
• 寻找系统保持正常负载的极限QPS
• 寻找API热点

故障原因

导致此次故障的原因即此次的性能瓶颈，主要是MySQL性能问题，CPU 95%以上，基本处于死机状态，大量的SQL查询超时导致客户端请求超时。

导致MySQL性能跟不上，原因是SQL不合理、设计不合理这两个点，本次优化也就着重这两部分内容。

关于两种不合理的简单理解：

• SQL不合理

SQL不合理比较容易理解，也就是