前言
这篇文章的主题是记录一次性能优化,在优化的过程中遇到的问题,以及如何去解决的。为大家提供一个优化的思路,首先要声明的一点是,我的方式不是唯一的,大家在性能优化之路上遇到的问题都绝对不止一个解决方案。
如何优化
首先大家要明确的一点是,脱离需求谈优化都是耍流氓,所以有谁跟你说在xx机器上实现了百万并发,基本上可以认为是不懂装懂了,单纯的并发数完全是无意义的。其次,我们优化之前必须要有一个目标,需要优化到什么程度,没有明确目标的优化是不可控的。再然后,我们必须明确的找出性能瓶颈在哪里,而不能漫无目的的一通乱搞。
需求描述
这个项目是我在上家公司负责一个单独的模块,本来是集成在主站代码中的,后来因为并发太大,为了防止出现问题后拖累主站服务,所有由我一个人负责拆分出来。对这个模块的拆分要求是,压力测试QPS不能低于3万,数据库负载不能超过50%,服务器负载不能超过70%, 单次请求时长不能超过70ms,错误率不能超过5%。
环境的配置如下:
服务器:4核8G内存,centos7系统,ssd硬盘
数据库:Mysql5.7,最大连接数800
缓存: redis, 1G容量。
以上环境都是购买自腾讯云的服务。
压测工具:locust,使用腾讯的弹性伸缩实现分布式的压测。
需求描述如下:
用户进入首页,从数据库中查询是否有合适的弹窗配置,如果没有,则继续等待下一次请求、如果有合适的配置,则返回给前端。这里开始则有多个条件分支,如果用户点击了弹窗,则记录用户点击,并且在配置的时间内不再返回配置,如果用户未点击,则24小时后继续返回本次配置,如果用户点击了,但是后续没有配置了,则接着等待下一次。
重点分析
根据需求,我们知道了有几个重要的点,
1、需要找出合适用户的弹窗配置,
2、需要记录用户下一次返回配置的时间并记录到数据库中,
3、需要记录用户对返回的配置执行了什么操作并记录到数据库中。
调优
我们可以看到,上述三个重点都存在数据库的操作,不只有读库,还有写库操作。从这里我们可以看到如果不加缓存的话,所有的请求都压到数据库,势必会占满全部连接数,出现拒绝访问的错误,同时因为sql执行过慢,导致请求无法及时返回。所以,我们首先要做的就是讲写库操作剥离开来,提升每一次请求响应速度,优化数据库连接。整个系统的架构图如下:
(ca, 还是没地方上传图片)
应用层:安卓+IOS+Web
接入层:LB
服务层: 主服务-》消息队列-》redis
|
DB
将写库操作放到一个先进先出的消息队列中来做,为了减少复杂度,使用了redis的list来做这个消息队列。
然后进行压测,结果如下:
QPS在6000左右502错误大幅上升至30%,服务器cpu在60%-70%之间来回跳动,数据库连接数被占满tcp连接数为6000左右,
很明显,问题还是出在数据库,经过排查sql语句,查询到原因就是找出合适用户的配置操作时每次请求都要读取数据库所导致的连接数被用完。因为我们的连接数只有800,一旦请求过多,势必会导致数据库瓶颈。
好了,问题找到了,我们继续优化,更新的架构如下
应用层:安卓+IOS+Web
接入层:LB
服务层: 主服务-》消息队列-》redis
| | |
DB ------------------------
我们将全部的配置都加载到缓存中,只有在缓存中没有配置的时候才会去读取数据库。
接下来我们再次压测,结果如下:
QPS压到2万左右的时候就上不去了,服务器cpu在60%-80%之间跳动,数据库连接数为300个左右,每秒tpc连接数为1.5万左右。
这个问题是困扰我比较久的一个问题,因为我们可以看到,我们2万的QPS,但是tcp连接数却并没有达到2万,我猜测,tcp连接数就是引发瓶颈的问题,但是因为什么原因所引发的暂时无法找出来。
这个时候猜测,既然是无法建立tcp连接,是否有可能是服务器限制了socket连接数,验证猜测,我们看一下,在终端输入ulimit -n命令,显示的结果为65535,看到这里,觉得socket连接数并不是限制我们的原因,为了验证猜测,将socket连接数调大为100001.
再次进行压测,结果如下:
QPS压到2.2万左右的时候就上不去了,服务器cpu在60%-80%之间跳动,数据库连接数为300个左右,每秒tpc连接数为1.7万左右。
虽然有一点提升,但是并没有实质性的变化,接下来的几天时间,我发现都无法找到优化的方案,那几天确实很难受,找不出来优化的方案,过了几天,再次将问题梳理了一遍,发现,虽然socket连接数足够,但是并没有全部被用上,猜测,每次请求过后,tcp连接并没有立即被释放,导致socket无法重用。经过查找资料,找到了问题所在,
tcp链接在经过四次握手结束连接后并不会立即释放,而是处于timewait状态,会等待一段时间,以防止客户端后续的数据未被接收。
好了,问题找到了,我们要接着优化,首先想到的就是调整tcp链接结束后等待时间,但是linux并没有提供这一内核参数的调整,如果要改,必须要自己重新编译内核,幸好还有另一个参数net.ipv4.tcp_max_tw_buckets, timewait 的数量,默认是 180000。我们调整为6000,然后打开timewait快速回收,和开启重用,完整的参数优化如下
#timewait 的数量,默认是 180000。
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.ip_local_port_range = 1024 65000
#启用 timewait 快速回收。
net.ipv4.tcp_tw_recycle = 1
#开启重用。允许将 TIME-WAIT sockets 重新用于新的 TCP 连接。
net.ipv4.tcp_tw_reuse = 1
我们再次压测,结果显示:
QPS5万,服务器cpu70%,数据库连接正常,tcp连接正常,响应时间平均为60ms,错误率为0%。
结语
到此为止,整个服务的开发、调优、和压测就结束了。
回顾这一次调优,得到了很多经验,最重要的是,深刻理解了web开发不是一个独立的个体,而是网络、数据库、编程语言、操作系统等多门学科结合的工程实践,这就要求web开发人员有牢固的基础知识,否则出现了问题还不知道怎么分析查找。
相关推荐
腾讯云SDK调用的QPS限制优化专用网关
用于WEB服务器端开发,介绍如何有效提升QPS、RT
MYSQL QPS TPS全揭秘,很多DBA都不知道的这个概念,呵呵
QPS:Queries Per Second 查询量/秒,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理查询量多少的衡量标准。 TPS : Transactions Per Second 是事务数/秒,是一台数据库...
awk测试从nginx查询qps的测试日志
基于ELK的nginx-qps监控解决方案.docx
QPS 高性能 qps 计数器安装$ npm install qps用法 var QPSCounter = require ( 'qps' ) ;var counter = new QPSCounter ( ) ;// plus onecounter . plus ( ) ;// current qpscounter . get ( ) ;应用程序接口...
sysbench基准测试并数据统计--TPS、QPS、TPMC及响应时间,让你第一时间了解数据库的运行情况。
NULL 博文链接:https://xiaohlang.iteye.com/blog/1001683
例子简介:通过CPU和IO的测试模型,观察CPU和IO时间消耗变化,而带来的QPS和RT的变化1、准备资源3台linux服务器(保证服务器的资源不会互相干扰,服
给DBA与运维工程师的QPS,PV和需要部署机器计算
QPS289Setup 2.04
控制服务器增长数量• 主题– 提升淘宝前台系统单服务器的QPS主要内容• QPS(吞吐量)三要素• 优化模板– 至少提升50%• 优化大数据的处理– 至少提升5%• 优化jvm参数– 资源太大,传百度网盘了,链接在附件中,...
对qps以及接口的平均耗时进行统计 特点 轻量: 共219KB(代码量约300行), 无需安装,加压即可使用 低侵入: 基于日志文件进行统计,无需修改原程序 使用说明 ...
基于cms的高并发低延时的gc参数,生产实战参数,各位看官烦请点赞
王亚雷-Twitter 千万 QPS 分布式系统的架构设计和高效运维
mysql数据库三个关键性能指标-TPS-QPS-IOPS,可以实时监控数据库运行情况,以便及时处理问题。
提升RabbitMQ单队列QPS的简单方案,文档分别去不同的集群进行了测试与优化
前两天有一个需求,需要访问某API服务器请求数据,该服务器限制了QPS=2(哈哈应该都知道是哪个服务器了吧_(:з」∠)_),因为QPS很小所以就使用阻塞式请求。后来开通了服务,QPS提高到了20,阻塞式请求满足不了这个QPS...
Quartus® Prime Standard Edition Handbook Quartus® Prime Standard Edition Handbook 可以下载看看