背景
公司为运营商做了一个项目；项目目的是为不同平台的接口提供统一的入口，也就是网关。作为网关必须有说得过去的性能指标，否则没有平台敢将自己的接口交给你；所以需要进行压力测试，给出压测报告。因为项目才初步上线，暂时制定的预期是 1W TPS
项目架构
组件结构图
生产机器配置
CPU 8核
内存 16G
硬盘 500G
机器属于 虚拟机共享状态 （通过之后调整为独享模式，发现对压测提升是巨大的；server从原来1k左右，能够提升到3.8k）
项目结构的性能瓶颈
- 首先Nginx自身的性能是很高，可以将其排除掉；
- gateway的性能，官方说的是到万的级别；用jmeter测试了带有业务的情况，TPS能够到2-2.5k；
- 剩下的就是server了，server用的是springboot 项目，内置的是tomcat容器，调优了tomcat相关的线程数之类，加上业务最终压测的结果是1-1.2k 左右 -- 所以说整个结构性能最差的是server，要对server进行横向的扩充。
调优过程
调优导图
如上图所示：
- 首先要知道压力测试的这些参数，我们的哪些指标能够体现我们的性能，哪些指标需要了解；
- 第二点是要对linux服务器进行优化
- 优化使用到的软件，数据库、NG等
- 优化我们的spring cloud微服务，调优代码设计结构；调优用到的组件：tomcat、robbin等
- 再就是调优发压软件 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压测结果图
