指标是：时间指标、容量指标和资源利用率指标
来自：01丨性能综述：性能测试的概念到底是什么？
18 人划过
只要每线程每秒的 TPS 开始变少，就意味着性能瓶颈已经出现了。但是瓶颈出现之后，并不是说服务器的处理能力（这里我们用 TPS 来描述）会下降，应该说 TPS 仍然会上升，在性能不断衰减的过程中，TPS 就会达到上限
来自：06丨倾囊相授：我毕生所学的性能分析思路都在这里了
15 人划过
在上面这张示意图中，其实压力工具是 4 个并发线程，由于每个线程都可以在一秒内完成 4 个事务，所以总的 TPS 是 16。这非常容易理解吧。而在大部分非技术人的脑子里，这样的场景就是并发数是 4，而不是 16。
来自：03丨性能综述：怎么理解TPS、QPS、RT、吞吐量这些性能指标？
11 人划过
而我们通常说的“并发”这个词，依赖 TPS 来承载的时候，指的都是 Server 端的处理能力，并不是压力工具上的并发线程数。在上面的例子中，我们说的并发就是指服务器上 100TPS 的处理能力，而不是指 5 个压力机的并发线程数。请你切记这一点，以免沟通障碍。
来自：05丨指标关系：你知道并发用户数应该怎么算吗？
10 人划过
由于用户数增加的幅度大于响应时间增加的幅度之前，TPS 仍然会增加，也就是说资源使用率达到饱和之后还有一段时间 TPS 才会达到上限
来自：02丨性能综述：TPS和响应时间之间是什么关系？
8 人划过
真正的性能工程师，可以把结果整理清楚之后，又可以下结论，提出解决方案
来自：开篇词丨“老板，之前咱TPS是100，我优化完是10000”
7 人划过
所以 Statistics 中的响应时间都是针对整个场景来说的，然而在梯度加压的过程中，用 Statistics 中的数据是不合理的。
来自：13丨性能测试场景：如何进行场景设计？
6 人划过
从生产数据统计，怎么转化到具体的场景中的业务模型
来自：14丨性能测试场景：如何理解业务模型？
4 人划过
比如说 JMeter。我们在运行结束后只能看到结果，但是不会有响应的信息。你也可以选择保存响应信息，但这会导致压力机工作负载高，压力基本上也上不去。也正是因为不存这些内容，才让一台机器模拟成千上百的客户端有了可能。
来自：11丨性能脚本：用案例和图示帮你理解HTTP协议
4 人划过
我们从实际的生产场景来看，压测工具模拟的是真实用户，而监控在哪里，在运维后台里，数据的流向都不一样。如果你使用压测工具的同时，也把它做为收集性能监控数据的工具，本身流量就会冲突。
来自：04丨JMeter和LoadRunner：要知道工具仅仅只是工具
3 人划过
*精彩内容为该课程各文章中划线次数最多的内容
讲师
高楼
前 HP 高级性能专家，7DGroup 创始人
编辑推荐
讲师的其他课程
包含这门课的学习路径
运维工程师
32门课程 149.1w人学习
测试工程师
18门课程 93.7w人学习
后端工程师
27门课程 184.1w人学习
看过的人还看了
