时间：x 月 x 日 地点：xx 公司测试部 人物：小菜、项目经理、大鸟
今天项目经理给小菜分配了一个性能测试任务，测试某个系统的 A 接口的性能是否能达到要求。项目经理告诉小菜，这个接口每天被 5000 个人调用，同时在线 500 人，每天要被调用 50000 次。
小菜一听，这个还不简单，立马拿 loadrunner 写好脚本 开始测试。过了没多久小菜测试完成写了一份报告发给项目经理：
- 并发 | 响应时间 | 应用服务器 cpu | 数据库服务器 cpu |TPS |
- 50 | 1s | 70% | 20% |50 |
- 100 | 1.3s | 95% | 30% |75 |
- 200 | 2.9s | 99% | 30% |70 |
- 500 | 7s | 99% | 30% |71 |
小菜结论：A 接口在 50 并发时应用服务器已经到达 70% 警报点，A 接口只能满足 50 人同时并发操作，建议增加应用服务器数量
项目经理看到小菜的报告通知运维部门增加 A 接口的服务器数量，可运维部门反馈：A 接口服务器目前日最高 CPU 只有 20% 并没有性能风险 项目经理生气的质问小菜怎么测试结果怎么和实际相差那么多。
小菜很郁闷，就去找从事测试工作七年的同事大鸟，请教原因。大鸟听了事情的经过，笑着说道：“小菜呀，你见过一个正常人在连续操作之间没有停顿的吗？“ 小菜恍然大悟，立马在脚本里加上 9 秒的 think time 重新测试：
- 并发 | 响应时间 | 应用服务器 cpu | 数据库服务器 cpu |TPS |
- 50 | 0.8s | 10% | 5% |5 |
- 100 | 0.9s | 20% | 10% |10 |
- 200 | 0.9s | 20% | 10% |20 |
- 500 | 1s | 70% | 20% |50 |
小菜看着测试结果感叹 同样是 500 并发，加了 think time 后差距为何会如此之大。
东哥牛逼，你是我的偶像
mark ，对我等小菜很有帮助
不错。以前用 LR 的时候前辈就教了最基础的两个点：think time 和 并发量的变化要以一定数量为步进逐步变。
话说表格的 markdown 是不是用错了？看起来有点像表格 markdown ，但实际又不是。
#3 楼 @chenhengjie123 表格在移动端太难看了 所以就用这种方式代替了
是否真的需要增加：think time ？
在调优阶段，要是做压力就不需要，要是模拟用户正式的操作就需要
另外希望大神多出点性能方面的小菜成长记。。
我做了 5 年的性能测试，不需要增加 thinktime，需要的是监控，找出问题，调优
接口每天被 5000 人调用，500 人同时在线，500 人同时在线，这 500 人并不是在循环不停的调接口，所以要模拟做压力/稳定性测试要，估算一个峰值，再去设置场景做；设置间隔，在脚本中加 think time 也是一种办法，最好是设置 pacing 值，在请求处理完成间隔多久后继续下一个/在间隔多久之后继续下一个。
貌似你要看 tps 的吧, 如果一秒钟处理 71 个请求，一分钟就是 4200 多个，如果 50000 中有个 5000 个分布就是在某个一分钟，你们系统可能也是扛不住的.估计你还是需要看请求的分布情况的.
#5 楼 @284772894 加不加完全看你的测试策略，是模拟用户 还是 模拟请求
think time 加不加，加多少，取决于实际应用。既然是一个已上线系统，你们居然不去找运营拿场景数据，直接自己 yy。。。。。。
很不错我来学学
我一般都不加，我做性能目的在于找出瓶颈，找出问题，然后让开发优化。 当然会尽可能的靠近实际情况。
学习了
