第一条虚线处的拐点代表着随着并发数的增加，资源利用率(CPU资源等)和吞吐量也在伴随着递增， 这个时候我们的响应时间有小幅度的增加，但是在可接受的范围之内；在这个点是做容量规划最好的参考点
第二条虚线处的拐点表示随着并发数的继续增加，系统资源已经到达了瓶颈，吞吐量开始明显下降，响应时间会大幅增加，也就是说已经到达了性能的瓶颈，请求队列开始挤压，这个时候已经严重影响用户体验或者有系统崩溃的风险。
：见下图，我的理解就是性能测试，找到最优的QPS(TPS)点容量测试：见下图，我的理解为压力测试，在达到性能瓶颈后继续加压，测试系统的最大承载量
新系统想要确定测试基准，就需要拿到数据，而产品一般是不会直接告诉我们QPS的，产品会告诉我们 PV/UV 天。
根据 PV、UV 再结合业务场景来计算确认我们的测试需求；将其转化为小时或分钟，或秒；另外业务场景可能会几种在某个时间段，比如工作日的8个小时时间：
UV：或者外卖产品则集中在午饭和晚饭的2个小时时间段，假如UV为1000w/天，那么高峰时段占了总用户数的80%：
PV：PV可以直接对应到QPS指标，好比一个电商产品，产品分别给出了首页、商品页、订单页的PV，便可依此来进行性能测试的基准设计。如果粗略的按24小时算QPS的话就是QPS = PV(天)/24/3600
2、根据具体的性能测试需求，确定测试类型以及压测的模块(web/mysql/redis/系统整体)
4、QA完成性能测试设计后，需产出测试方案文档发送邮件到项目组，并且再次与相关人员沟通(或者组织性能测试评审)，确认是否满足需求
现在我们可以利用Linux三剑客中的awk命令配合上排序的shell命令对log进行提取过滤,找出访问量最高的请求：
：比如用户浏览主页的PV和浏览商户的比例为1：2，那么接口的比例设计也就按照1：2来设计。
(3) 多线) 运行完脚本会生成jtl日志，可在Win、Mac环境界面中查看、统计
3.命令启动，Jmeter 本身也是软件，也有自己的承载限制，所以真正测试过程还是要以命令行运行的方式，UI 可以作为编写和调试脚本使用
以上只是做了个性能测试的基础知识铺垫，后续在此理论基础上，以电商业务为背景，结合
⬇️ 复制“下方链接”，提升测试核心竞争力！更多技术文章分享和免费资料领取