记一次性能优化,单台4核8G机器支撑5万QPS

2021年09月15日 阅读数:1
这篇文章主要向大家介绍记一次性能优化,单台4核8G机器支撑5万QPS,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

前言

这篇文章的主题是记录一次Python程序的性能优化,在优化的过程当中遇到的问题,以及如何去解决的。为你们提供一个优化的思路,首先要声明的一点是,个人方式不是惟一的,你们在性能优化之路上遇到的问题都绝对不止一个解决方案。html

如何优化

首先你们要明确的一点是,脱离需求谈优化都是耍流氓,因此有谁跟你说在xx机器上实现了百万并发,基本上能够认为是不懂装懂了,单纯的并发数彻底是无心义的。其次,咱们优化以前必需要有一个目标,须要优化到什么程度,没有明确目标的优化是不可控的。再而后,咱们必须明确的找出性能瓶颈在哪里,而不能漫无目的的一通乱搞。前端

需求描述

这个项目是我在上家公司负责一个单独的模块,原本是集成在主站代码中的,后来由于并发太大,为了防止出现问题后拖累主站服务,全部由我一我的负责拆分出来。对这个模块的拆分要求是,压力测试QPS不能低于3万,数据库负责不能超过50%,服务器负载不能超过70%, 单次请求时长不能超过70ms,错误率不能超过5%。linux

环境的配置以下:
服务器:4核8G内存,centos7系统,ssd硬盘
数据库:Mysql5.7,最大链接数800
缓存: redis, 1G容量。
以上环境都是购买自腾讯云的服务。
压测工具:locust,使用腾讯的弹性伸缩实现分布式的压测。web

需求描述以下:
用户进入首页,从数据库中查询是否有合适的弹窗配置,若是没有,则继续等待下一次请求、若是有合适的配置,则返回给前端。这里开始则有多个条件分支,若是用户点击了弹窗,则记录用户点击,而且在配置的时间内再也不返回配置,若是用户未点击,则24小时后继续返回本次配置,若是用户点击了,可是后续没有配置了,则接着等待下一次。redis

重点分析

根据需求,咱们知道了有几个重要的点,一、须要找出合适用户的弹窗配置,二、须要记录用户下一次返回配置的时间并记录到数据库中,三、须要记录用户对返回的配置执行了什么操做并记录到数据库中。sql

调优

咱们能够看到,上述三个重点都存在数据库的操做,不仅有读库,还有写库操做。从这里咱们能够看到若是不加缓存的话,全部的请求都压到数据库,势必会占满所有链接数,出现拒绝访问的错误,同时由于sql执行过慢,致使请求没法及时返回。因此,咱们首先要作的就是讲写库操做剥离开来,提高每一次请求响应速度,优化数据库链接。整个系统的架构图以下:shell

clipboard.png

将写库操做放到一个先进先出的消息队列中来作,为了减小复杂度,使用了redis的list来作这个消息队列。数据库

而后进行压测,结果以下:编程

QPS在6000左右502错误大幅上升至30%,服务器cpu在60%-70%之间来回跳动,数据库链接数被占满tcp链接数为6000左右,很明显,问题仍是出在数据库,通过排查sql语句,查询到缘由就是找出合适用户的配置操做时每次请求都要读取数据库所致使的链接数被用完。由于咱们的链接数只有800,一旦请求过多,势必会致使数据库瓶颈。好了,问题找到了,咱们继续优化,更新的架构以下segmentfault

clipboard.png

咱们将所有的配置都加载到缓存中,只有在缓存中没有配置的时候才会去读取数据库。

接下来咱们再次压测,结果以下:
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开发人员有牢固的基础知识,不然出现了问题还不知道怎么分析查找。

ps:服务端开启了 tcp_tw_recycle 和 tcp_tw_reuse是会致使一些问题的,咱们为了优化选择牺牲了一部分,得到另外一部分,这也是咱们要明确的,具体的问题能够查看耗子叔的文章TCP 的那些事儿(上)

关于做者

    • Leoython,擅长Javascript, Python, Go,最近在研究Rust和k8s
    • E-Mail: leoython@gmail.com
    • 文章编写于: 2019/01/31