你好，我是小牛
之前写过一篇关于如何自学性能测试的文章，详情参考文章：
如何自学性能测试？
关于工作中用不到性能测试为什么还要进行学习之类的就不多说了，文章中都有提到。今天来聊聊当你准备对一个系统进行压测时，如何确定它的压测目标TPS？
首先，这道题不仅工作中会遇到很实际的问题，前段时间小牛去面试也经常会被问到，详情参考文章：
最近面试了几家公司，分享一波经验！
今天就来写写应该怎么做以及面试遇到这种问题应该怎么进行回答，有哪些思路可以供大家参考。
首先，一个较为理想的情况就是你们公司系统已经上线很久了，比较稳定，或者之前上线过类似的产品或者项目。之前也在测试环境做过压力测试，只要TPS达到某个数值，生产基本就不会有问题。
就比如小牛公司就是这种情况，我们公司是做保险相关业务的，每隔一段时间或者到一些节日就会推出一些新的产品。
虽然每款产品都不同，但是之前因为有大量的经验作为积累和参考，所以对生产峰值都是有很好评估的。
根据以往经验，只要测试环境可以承受主1200的TPS，生产投保就不会有什么问题。
而且生产配置机器数量是测试环境的4倍。所以业务和领导直接把TPS1200列为了我们测试环境压测优化目标。
这个确定下来之后，接下来好办了，无非就是设置各种压测场景，比如单接口，混合场景，长时间稳定性测试等等对服务器做压力测试。
压测之前，先对各个数据流转系统做好监控，比如服务器硬件资源cpu，磁盘，网络，io以及数据库服务器，包括线程状态，中间件等等做监控。
然后，进行施压，找到性能拐点，达不到的话就根据监控逐个分析排查瓶颈在哪里，很多时候都是交给开发去进行优化，直到达到目标TPS1200即可。
以上，说的是一种理想情况，然而很多公司情况并不是这样的。
比如有些公司上线了一些老系统，已经运行了一年半载的，但是之前没做过性能测试，领导想做下压测看下系统最大支持多少并发，需不需要购买服务器加配置之类的。
这个时候我们要分析，系统最大TPS应该怎么做呢？
首先，在一些比较成熟或者有些规模的公司，一般都有各种各样的业务监控系统，定期监控各业务模块的核心接口的调用量，平均耗时等等。一般是以分钟为级别进行监控。
这个时候，我们就可以看该系统过去一周，甚至一个月访问量调用量最大的那一天，然后去找到该天调用量最大的峰值，精确到分钟级别。
比如晚上八点10分调用量最大为12000次，那么我们就可以计算出最大TPS为12000除以60为200。
那么接下来，可能有的小伙伴就说了，我们公司没那么牛逼，没有这样的监控系统，那么应该怎么做呢？
没监控系统，打印日志总该有吧，这个再没有的话说实话建议你尽快跳槽吧，不宜久待。
有日志的话，可以看下中间件的访问日志，比如nginx的access.log，日志中详细记录了每个http请求的，访问时间，url，响应时间和状态码。
有了这些数据就好办了，我们可以编写脚本，统计出接口在哪个时间段访问量最高，多长时间调用多少次，然后跟上面方法一样进行计算确定TPS。
啥，不会编写脚本？请运维大佬吃个饭，帮你写个脚本还不是轻轻松松。
当然，接下来还有比较多的一种情况，就是我们这是个新项目，生产上面没数据，那么怎么确定TPS呢？
这个时候，还有一种方法可以进行参考，就是二八定律。这个相信大家之前都听说过，世界上百分之八十的财富掌握在百分之二十的人手里。
同样的，适用于互联网领域，百分之八十的用户在一天中百分之二十的时间进行访问。系统性能如果能支撑百分之二十时间的并发，其它时间也能支持。
接下来详细进行说说怎么评估计算呢？
比如一个系统上线了一个抽奖活动，想评估下多大TPS可以顶住峰值。网站注册用户一千万，日活用户100万。
那么我们就可以根据这一百万用户在一天时间的访问进行估算。首先要考虑的是这100万不会都来参加抽奖，但是我们要保证最大tps，所以可以取极端值，用100万进行计算。
其次晚上12点到凌晨6点一般访问量极低，所以可以去掉这六个小时，按照18个小时计算。
那么根据二八定律，百分之八十的用户在百分之二十的时间访问。用户量就是100万乘以百分之八十，为80万请求。
时间就是18小时乘以百分之二十乘以3600秒为12960秒，那么TPS=80万除以12960秒为60左右。
虽然这种方式并没有上面那种查看业务监控以及中间件日志来的准确，但是总比你面试拍脑袋瞎说好的多，这也是一种分析思路。
面试只要说的有理有据，其实很多时候并没有标准答案。
可能，有些小伙伴又说了，别整这些有的没的，我们系统没监控，也没日志，也不知道日活是多少，怎么办呢？
这种情况的话建议就不要管什么指标了，直接进行压测吧，然后把压测结果报告写清楚发给相关领导，让他们开会讨论，最后拍板决定是要达到多少TPS来保证生产业务并发量。
