服务压测优化

背景

公司为运营商做了一个项目；项目目的是为不同平台的接口提供统一的入口，也就是网关。作为网关必须有说得过去的性能指标，否则没有平台敢将自己的接口交给你；所以需要进行压力测试，给出压测报告。因为项目才初步上线，暂时制定的预期是 1W TPS

项目架构

组件结构图

生产机器配置

CPU 8核

内存 16G

硬盘 500G

机器属于 虚拟机共享状态 （通过之后调整为独享模式，发现对压测提升是巨大的；server从原来1k左右，能够提升到3.8k）

项目结构的性能瓶颈

1. 首先Nginx自身的性能是很高，可以将其排除掉；
2. gateway的性能，官方说的是到万的级别；用jmeter测试了带有业务的情况，TPS能够到2-2.5k；
3. 剩下的就是server了，server用的是springboot 项目，内置的是tomcat容器，调优了tomcat相关的线程数之类，加上业务最终压测的结果是1-1.2k 左右 -- 所以说整个结构性能最差的是server，要对server进行横向的扩充。

调优过程

调优导图

如上图所示：

1. 首先要知道压力测试的这些参数，我们的哪些指标能够体现我们的性能，哪些指标需要了解；
2. 第二点是要对linux服务器进行优化
3. 优化使用到的软件，数据库、NG等
4. 优化我们的spring cloud微服务，调优代码设计结构；调优用到的组件：tomcat、robbin等
5. 再就是调优发压软件 jmeter，主要就是调整堆栈内存

调优内容

压测指标

TPS

即单位时间（一般是一秒）内处理请求的数量，也叫事务数、吞吐量，是衡量并发系统非常重要的指标；本次压测就是以这个指标为准。

简单计算规则： 如果请求的用户数是1，响应时间是1ms，那么计算出来的TPS就是1000；如果响应时间是1s，TPS就只有1，想要达到TPS 1000，就需要将用户数增至1000；因此可以说1个用户可以产生1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。

RT

响应时间；也就是一次用户请求，到返回内容的时间。这个对于用户来说是最直观的感受。当然不同业务，不同时间段，响应时间也是不同的。

QPS

query per second；一秒内请求的数量。个人感觉是用来反映你这个系统体量的。和TPS不同，QPS只是请求的数量，而TPS是指从请求到返回一个完整流程。

Jmeter压测结果图