甲方要求：系统每天访问人次应满足 100 万人，同时在线用户数 1000 人，日订单量支持 10 万订单数，每秒事务处理约为 250 笔。
需求拆解：
1、24 小时内持续访问至少 100 万个请求；思路：以登录接口为例，线程数设置 1000，循环次数设置 1000，调度器持续时间设置 86400s；
2、同时在线 1000 人；思路：以登录接口为例，线程数设置 1000，rampuptime 设置 10s；
3、24 小时提交订单 10 万个；思路同 1，改为提交订单接口；
4、每秒事务处理 250 笔，相当于 TPS 为 250/s；思路：线程数从 250 往上逐渐加，rampuptime 设置 1s，查看 TPS 是否达到要求；
疑问：使用 CLI 模式时，施压机器进行其他操作对压测结果影响大吗？比如我一边在跑脚本，一边在浏览社区文章；
(没做过性能测试，第一次接到这样的任务，希望大佬指正)
不知道你是在什么环境下做的测试，如果是在测试环境中进行性能测试时，由于硬件资源和配置的限制，直接模拟生产环境的负载可能不现实，建议你先了解下，然后等比例缩放
1.1000000/86400=12~
2.在线不建议使用登录接口，可以考虑使用内部高频接口
3.持续提交？是的话没必要测了。除非提交订单会附带运算类处理
4.持续并发，逐步递增
5.单页签查看影响可忽略
不要被客户描述欺骗了，这是四个需求，需要分别测试
1.客户想知道订单处理 TPS，大于 250 每秒为合格
2.客户想知道每天 10 万的数据量系统如何表现，无异常为合格
3.客户想知道系统能支持多少人同时使用，1000 人为合格
4.客户想知道 100 万人次的数据量系统如合表现，无异常为合格
今晚打老虎
回复
1000000/86400=12~
没理解你的意思，那 24 小时满足 100 万人访问要怎么设计？
日订单数支持 10 万单不就对应提交订单接口吗？
光影风
回复
我已经分解成四个测试需求了，分别测试的话用例和配置都是不一样的。我没有用过 jmeter，我都是用自己开发的工具进行测试，所以我都不关心线程数量，只关心用户数和业务，参见这个 https://testerhome.com/topics/39936，有兴趣可以研究下
线程设置太大，比如 1000，施压机器自己就先崩了，接口大量报超时
要怎么解决，没有条件做分布式测试
系统每天访问人次应满足 100 万人这个我觉得不能均摊到一整天吧，那样太理想了，建议设计一下波峰，比如从上午 9 点到晚上 21 点这个期间的访问量占据 80% 的访问量，会更符合实际一些。
1.百万请求，就是百万 pv，线程数不用设置那么大，根据响应时间进行，具体可以看这个【如何带妹进行 1000000PV 的 jmeter 场景压测 - CSDN App】http://t.csdnimg.cn/v0Qbs
光影风
回复
1、2、4 对应的线程数使用梯度增加的方式，慢慢增加线程数，在压测过程中关注是否达到客户要求的指标数
3 需要使用 1000 线程压测一定的时间，看是否有异常，压测时间就看你们是怎么定的了
1、系统每天访问人次应满足 100 万人，需求不太明确
2、同时在线用户数 1000 人，可以设置为 1000 线程，毕竟一个用户至少要占用一个长连接；
3、日订单量支持 10 万订单数，那么平均 TPS 为：100000/(24*3600)=1.12，考虑到用户大多在白天进行操作，可以假设用户使用系统的时间为 8 个小时，那么下订单的 TPS 为：100000/(8*3600)=34.7 笔/秒；
4、每秒事务处理约为 250 笔，这里应该指的是所有业务的总 TPS 为 250 笔/秒，那么你就需要知道这个被测系统 TOP10~TOP20 业务包括哪些，然后把这些业务按照比例进行分配，总 TPS=250。
综上，使用 Jmeter 工具设置 1000 个线程数，然后使用吞吐量控制器分配每个业务的 TPS 占比，保证总的 TPS 达到 250 左右，持续运行 24 小时后，请求数量可达到 2160 万。
注意：使用 Jmeter 工具压测时官网建议使用 CLI 模式，且压测过程中最好不要使用压力机进行一些占用 CPU、内存资源的操作，会影响压测结果。如果条件允许，可以申请一台 4c8g 的 Linux 服务器执行压测。
corei99
回复
谢谢你的指正！3、4 点学到了！
系统每天访问人次应满足 100 万人
意思就是 24 小时内要能满足 100 万人的访问，这 100 万的人是可以重复的；比如 50 万人访问，每人都访问了 2 次，当然这个访问不局限某个接口，就是他来过
还有个疑问：为什么同一个脚本，CLI 模式居然比 GUI 模式的响应时间还慢这么多？
1、每天 100 万人访问，一天按照常识可以粗略估计一天 10 小时，根据系统特性分析这 100 人的集中登录时间，如果无法获取，粗略根据 2/8 法则，80%（800w) 的流量集中在 20%(10*20%*3600) 时间内访问，800w/7200 大约 110 的 tps
2、同时在线 1000 人，这 1000 人登录这个网站会进行哪些操作，模拟相关的查询接口，下单接口等，将相关的接口串行，中间做等待时间，比如某个查询后，浏览 20 秒钟后下单等，启动 1000 个线程循环执行上述流程一段时间，一般观察一段时间的资源，资源使用稳定既可，也可以做一天的持续测试
3、4 可以放一起，根据单个下单接口的响应时间，制定下单并发数以满足 tps 达到 250，比如单个下单接口响应时间为 0.5 秒，那你起 125 个线程并发，即可满足下单接口达到 TPS 250，10w/250 = 400 秒，保证 125 并发执行 400 秒就可以了
最后，实际操作中可以适当扩大指标，做一定的冗余设计，比如对各个指标要求提高 20%
YHC
回复
通俗易懂！喜欢这样的解答！
单个下单接口响应时间为 0.5 秒，那你起 125 个线程并发，即可满足下单接口达到 TPS 250 。这样算不对吧？1 个 0.5s，那 125 个不就耗时 62.5s 了，TPS 怎么能是 250 呢
mdd~
回复
一个线程响应时间 0.5 秒，那么一个线程在一秒钟就能产生 2 个请求，125 个线程在一秒钟就能产生 250 个请求，即 tps = 250
适用二八原则
学到很多
学到了、感谢大佬
