对系统进行压测，比如每秒压个几百请求到几千请求，甚至上万请求，此时发现死活压不上去，压来压去，你的系统最多每秒就处理几百个请求，根本到不了几千个请求，此时就发现系统的TPS不达标，此时如何优化？
其实这个时候，如果发现TPS不达标，通常是说明你系统肯定是每个请求处理时间太长了，所以就导致你单位时间内，在有限的线程数量下，能处理的TPS就少了，这个时候往往要先优化性能，再提TPS
假设你一共有200个线程，结果你每个请求要耗费500ms，每个线程每秒就只能处理2个请求，200个线程每秒只能处理400个请求，比你期望的单机处理500~600个请求，要少了很多
既然说要优化性能，那就得通过打日志的方式，或者是监控的方式，检查你服务的每个环节的性能开销，通常来说用打日志方式会细化一些，要靠监控把每个细节摸清楚，也挺难的，毕竟很多是代码细节
把你的系统里一个请求过来，每一次数据库、缓存、ES之类的操作的耗时都记录在日志里面，把你的每个请求执行链路里的每个耗时小环节，都给记录清楚他，比如说你一个请求过来一共500ms，此时你发现就是某个SQL语句一下子耗时了300多ms，其实其他的操作都在正常范围内
优化一下SQL语句呢？这个SQL语句搞了一个全表扫描，因为写SQL的时候没有考虑到使用索引，所以此时可以建立新的索引，或者是改写SQL语句，让他可以使用到你建立好的索引，SQL语句优化到100ms
每个请求只要300ms就可以了，每个线程每秒可以处理3个请求，200个线程每秒可以处理600个请求
你可以检查你核心服务的每个环节的性能，针对性的做优化，把你每个请求的时间降到最低，这样你单位时间内的TPS绝对就提高了，这个很关键
其次就是增加机器数量，线性扩容了，比如说服务层面，每个服务单机最多抗800请求，那扩容到部署10台机器，就可以抗8000请求，但是你又得考虑你依赖的数据库，MQ，Redis能不能抗下这么多的并发