04丨JMeter和LoadRunner：要知道工具仅仅只是工具

Dec 23, 2019

04丨JMeter和LoadRunner：要知道工具仅仅只是工具-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

04丨JMeter和LoadRunner：要知道工具仅仅只是工具

2019-12-23 高楼来自北京

《性能测试实战30讲》

课程介绍



讲述：高楼

时长25:57大小17.80M



做性能测试工作的人总是离不了性能测试工具，但当我们刚开始接触这类工具或者压测平台的时候，总是难免处在一种顾此失彼，焦虑又没想法的状态。
性能工程师的三大学习阶段在我看来，对性能测试工程师本身来，多半会处在以下三个大的阶段。
性能工具学习期JMeter 和 LoadRunner 是我们常用的两个性能测试工具。曾经有人问我，应该学 JMeter 还是 LoadRunner 呢？我反问的是，你学这样的工具需要多久呢？一般对方因为初学并不清楚要多久，然后我会告诉他，如果你是认真努力的，想要全职学习，那么我觉得一个工具，纯从功能的使用的角度来说，自学两个星期应该就差不多了。如果你是在工作中学习，那就更简单了，工作中需要什么就学习什么，不用纠结。
而应该纠结的是什么呢？当你把 JMeter、LoadRunner 的基本功能学会了，你会发现这些工具其实就做了两件事情，做脚本和发压力。
但问题在于，脚本的逻辑和压力场景的逻辑，和工具本身无关，和业务场景有关。这时你可能就会问，场景怎么配置呢？
这才进入到了另一个阶段。
通常在这个阶段的时候，你会觉得自己有非常明确的疑问，有经验的人可能一句话就可以指点你了，解决掉你的疑问，就是告诉你选择什么工具，如何来用。
性能场景学习期第二个阶段就是性能场景学习期。我们平时在很多场合下所说的场景范围都有些狭隘，觉得场景就是业务比例，就是用多少数据。而实际做过多个性能项目之后，你就会发现，工具中的一个小小的配置，也会对结果产生巨大的影响。
比如说压力策略，应该用一秒 Ramp up 10 个用户，还是 20 个用户，还是 100 个用户？这应该怎么判断呢？
比如说，参数化数据应该用 100 条，还是 100 万条？还是有确定的值呢？有人说根据场景配置，可是根据什么样的场景怎么配置才合理呢？
比如说，在执行场景时应该看哪些数据？压力工具中的 TPS、响应时间这些常规数据都会去看，其他的还要看什么呢？这就涉及到了监控策略。
再比如说，业务应该用什么样的比例设置到压力工具中？有人说直接在线上做测试不是挺直接？但是你知道什么样的业务可以，什么样的业务不可以吗？如何控制线上的性能测试？
在性能场景学习期这个阶段，你关心的将不再是工具的使用操作，而是如何做一个合理的性能测试。你可以学会调整业务比例，并设计到压力工具中；你可以学会参数化数据的提取逻辑；你可以学会场景中要观察哪些数据。
按照这个思路，再做几个项目，你就会慢慢摸着一些门道。
性能分析学习期学会使用工具了，也有了场景设计的经验，通过监控工具也拿到了一堆大大小小的数据。可是，数据也太多了，还在不断的变化。我又怎么判断性能瓶颈在哪里呢？
做性能的人都会有这样的一个茫然。当你把一个性能测试结果发给了别人，别人会顺理成章地去问你：“响应时间为什么这么长？有没有优化空间？”
听到这种问题，你有没有无助的感觉？心里台词是：“我怎么知道？”但是嘴上却不敢说出来，因为似乎这是我应该给出的答案？
但是当你尝试给出答案时，你就进入了一个大坑，对这个问题做出回答，近乎一个无底洞，需要太多的基础知识，需要很强的逻辑分析，需要清晰的判断思路。
如果你到了这个阶段，你可能会发现自己走得非常痛苦，好像自己也不知道自己会什么，不会什么。要说工具吧，也完全会用，场景吧，也会配置，但为什么就是不会分析结果，不会整理数据，不会下结论呢？
但实际上，我觉得你不要焦虑自己不会什么，而应该把目光聚焦到你要解决的问题上。问题的解决，靠的是思维逻辑，靠的是判断，而不是靠工具。
也就是说，这时面对问题，你应该说的是“我想要看什么数据”，而不是“把数据都给我看看”。
看到这里，希望你能清晰地理解这两者之间的区别。
公司性能团队成长阶段我刚才分析了一下作为个人的性能工程师是如何一步步成长的，在实际工作中，我们更多的需要与团队合作，团队的成长与我们个人的成长息息相关。
对于一个公司的一个性能团队来说，大概会处在这些阶段。
性能团队初建这时的团队，可以执行场景，可以拿出数据，但工作出的结果并不理想。团队整体的价值就体现在每天跟着版本跑来跑去，一轮轮地测试下去，一个版本短则一两个星期，长则一个月。没有时间去考虑测试结果对整个软件生命周期的价值，在各种琐碎的项目中疲于奔命。做脚本，拿出 TPS 和响应时间，做版本基线比对，出数据罗列式的性能测试报告。
唉，想想人生就这么过去了，真是心有不甘。这时有多少人希望能有一个性能测试平台来拯救团队啊。
性能团队初成熟到了这个阶段，团队已经可以应付版本的更迭带来的性能工作压力，团队合作良好，稍有余力，开始考虑团队价值所在，在公司的组织结构中应该承担什么样的职责。在产品的流水线上终于可以占有一席之地了。这样很好，只是从实际的技术细节上来说，仍然没有摆脱第一阶段中琐碎的工作，没有把性能的价值体现出来，只是一个报告提供机器。
这时就需要考虑平台上是不是可以加个 SLA 来限制一下？在各个流程的关卡上，是不是可以做些性能标准？是不是该考虑下准入准出规则了？是的，这时一个团队开始慢慢走向成熟，站住脚之后要开始争取尊重了。
性能团队已成熟有了标准、流程，团队的合作能力也成熟了之后，团队“是时候展示真正的实力了”。但问题来了，什么才是性能团队的真正实力呢？
直观上说，主要体现在一下几个方面。
1. 通过你的测试和分析优化之后，性能提升了多少？
这是一句非常简单直接的话。但是我相信有很多做性能测试工程师的人回答不出这样的问题。因为看着混乱的 TPS 曲线，自己都已经晕了，谁还知道性能提升了多少呢？
而一个成熟的团队应该回答的是：提升了 10 倍，我们调优了什么。这样的回答有理有据，底气十足。
2. 通过你的测试和分析优化之后，节省了多少成本？
这个问题就没有那么好回答了，因为你要知道整体的容量规划，线上的真实运营性能。如果之前的版本用了 200 台机器，而通过我们的测试分析优化之后，只用到了 100 台机器，那成本就很明显了。
但是，在我的职业生涯中，很少看到有人这样来体现性能存在的价值。有些场合是不需要这样体现，有些场合是不知道这样体现。
对个人以及团队来说，工具应该如何选择理顺了性能测试工程师和性能团队的成长路径，下面我们来说说个人或者团队选择工具的时候，应该如何考量。
在我十几年工作的生涯中，可以说有很多性能工具都是知道的，但是要说起用得熟练的，也无非就是那几个市场占有率非常高的工具。
下面列一下市场上大大小小、老老少少、长长短短的性能测试工具，以备大家查阅。
市面上大大小小的性能测试工作一共有四十余种。这里面有收费的，也有免费的；有开源的，有闭源的；有新鲜的，有不新鲜的；有活跃的，有半死不活的；有可以监控系统资源的，有只能做压力发起的。
你是不是有一种生无可恋的感觉？一个性能测试而已，有必要搞出这么多工具吗？
然而，你要记住，这些都是压力发起工具。
下面我对一些比较常见的工具做下比对，这些工具主要包括 Apache JMeter、HP LoadRunner、Silk Performer、Gatling、nGrinder、Locust 和 Tsung。
仅比对这几个工具吧，因为从市场上来说，这几个算是经常看到的工具，以后我们再加入其他的工具和其他的属性。我们现在只说性能工具，不说一些企业做的性能平台云服务，因为云服务都是对企业来说的，我们放到后面再讲。
你从网络上可以很容易地找到这几个工具的特点，这几个都支持分布式。从上面那张表格中，你可以很容易对比出来，知道自己应该学什么工具了。
Gatling 有免费版和收费版，基于 Scala 语言，而 Scala 又是基于 Java 的，你看这复杂的关系就让人不想用，但是这个工具性能很高，虽说只支持 HTTP，但是由于支持 Akka Actors 和 Async IO，可以达到很高的性能。Actors 简化并发编译的异步消息特性让 Gatling 性能很高。
Locust 这个工具是基于 Python 的，中文名翻译过来就是蝗虫，这名字取得挺有意思。在一个压力场景下，对服务器来说确实就像一堆蝗虫来了。
对市场的占有率来说，JMeter 和 LoadRunner 以绝对的优势占据前两名，同时 JMeter 又以绝对的优势占据第一名。
下面来看一下，这两个工具的热度趋势。
这是全球范围近 5 年 JMeter 和 LoadRunner 热度（红色线是 LoadRunner，蓝色线是 JMeter）：
中国范围近 5 年 JMeter 和 LoadRunner 热度：
从上面的比对来看，我们可以很容易发现，近五年来，LoadRunner 就一直在走下坡路，而 JMeter 一直处在上升的趋势。
JMeter 和 LoadRunner 的历史兴衰我下面只说一下 JMeter 和 LoadRunner 的历史，让你对性能工具的兴衰史有一定的了解。
先说说 LoadRunner 吧，应该说，LoadRunner 的历史，就是一段悲惨的回忆。2006 年 11 月份以前，在 Mercury 时代，LoadRunner 由于市场策略和工具优势很快占了第一名，势头很猛。当时还有另一个同样功能的工具 Silk Performer，被打压得几乎抬不起头来。06 年以后，Mercury 以 45 亿美元被 HP 收购，包括 QC、QTP 等工具。但从那之后，LoadRunner 的体积就在飞速膨胀，8.1 的 LoadRunner 只有 600M 左右（如果我没记错的话），经历了几个版本的迭代，LoadRunner 成功膨胀到 4 个 G，并在后面规划 performance center，在各地做质量中心。HP 这一步步走得理直气壮，把市场折腾没了。现在 LoadRunner 如果想装到一台压力机上，都是很吃力的事情。我要是用的话，宁愿在 XP 系统上安装 8.1 版本，速度飞快。2016 年，HPE 和 MicroFocus 合并，LoadRunner 也成了 MicroFocus 产品线的一部分，搞到现在，在中国的市场依然疲软。
而拥有同样竞品工具 Silk Performer、Silk Test 和 Silk Test Manager 的 Segue 公司，同年仅以 1 亿美元被另一个企业 Borland 收购。3 年之后，Borland 连同自己，以 7500 万美元卖给了 MicroFocus。
至此，MicroFocus 同时拥有了 LoadRunner 和 Silk  Performer。但可惜的是，这也照样干不过一个无心插柳柳成荫的开源工具 JMeter。
JMeter 的历史，可以说是屌丝逆袭的典型案例。1998 年，Apache 基金会的 Stefano Mazzocchi 是它最初的开发者，当时他只是为了测试 Apache JServlet 的性能（这个项目后来被 Tomcat 取代），后来 JMeter 被重构，又被用来测试 Tomcat。其实一开始，JMeter 的功能很简单。但是 Apache Tomcat 的势头实在是阻挡不住，再加上 Java 市场覆盖率实在是太高了，而 JMeter 做为一个开源免费的 Java 压力工具，有着众多的 contributors，顶着 Apache 的大旗，想失败都难。就像 ab 工具是为了测试 Apache HTTP  server 一样，JMeter 应该说是和 Apache Tomcat 一起成长的。
与此同时，还有另一个 Java 开源工具 The Grinder，这个工具的主要贡献者是 Philip Aston、Calum Fitzgerald。
当时有一个开源测试平台叫 NGrinder，是韩国公司 NHN 开源的。有很多所谓企业内部自研发的性能测试平台，就是从 NGrinder 借鉴来的，而 NGrinder 就是以 The Grinder 为基础开发的。可惜的是，The Grinder 没有 Apache 这样的平台，作为一个很优秀的工具，它的维护更新还是不够快，不过 NGrinder 也给它带来了一定的荣耀。
到现在为止，JMeter 还没有一个非常成熟的云测试平台支撑它，只有一些商业公司改动，加一些管理和项目属性，做为企业内部平台使用。还有一些企业把 JMeter 改造成商业产品，加上云基础架构的管理功能，就成了一套完整的商业平台，再加上炫丽的操作页面，棒棒的，有没有？
那么你有没有想过，为什么没有以 JMeter 为基础的开源云测试平台呢？难道 JMeter 的热爱者看不到云测试平台的价值吗？在我看来，做为性能测试工具，它实在是没有必要做成一个开源的测试平台，因为轮子就是轮子，要装成什么样的车就自己装吧。要是再换个角度来说，性能测试真的有必要用平台吗？
使用性能测试工具的误区在哪里现在很多人都是看互联网大厂的技术栈，但是有没有想过自己企业需要的到底是什么样的产品？曾经有个测试工程师跟我说，他们公司为了解决性能问题，特意买了压测云服务，花了 20 万，结果问题还是没找出来。
所以工具应该如何用，完全取决于用的人，而不是工具本身。
压测工具也好，压测平台也好，都没有一个工具可以直接告诉你瓶颈在哪里，能告诉你的只是数据是什么。分析只有靠自己，在这个过程中，我们也会用到很多的分析剖析工具，用这些工具的人也都会知道，工具也只提供数据，不会告诉你瓶颈点在哪里。
那这个时候就有人提出疑问了：“有些工具不是说，上了这个工具之后，耗时一眼看透嘛？”是的呀，关键是你看过是什么耗时了吗？给你一个 Java 栈，那么长的栈，每个方法的消耗都给你，但是长的就肯定有问题吗？
关于剖析工具的，我们后面再写。本篇重点在压测工具上。
有人说 JMeter BIO 有问题，应该用 AIO；有人说，压测工具没有后端系统性能监控数据，应该加一个监控插件。像 JMeter 中就有一个插件叫 perfmon，把后端的系统资源拉到 JMeter 的界面中来看。在这一点上，LoadRunner 老早就做过了，并且在之前的版本中还有个专门的组件叫 tuning，目的就是把后端所有的系统、应用、数据库都配置到一个架构图中，压力一发起，就把有问题的组件标红。想法很好，可是这个功能为什么没有被广泛使用？当然，后面被 HP 收购后，这和 HP 的市场策略有关，但是在收购前的 Mercury 时代，该功能也没有被广泛使用。
我们从实际的生产场景来看，压测工具模拟的是真实用户，而监控在哪里，在运维后台里，数据的流向都不一样。如果你使用压测工具的同时，也把它做为收集性能监控数据的工具，本身流量就会冲突。
所以在压测工具中同时收集监控计数器，就是不符合真实场景的。
这样压测平台就有出现的必要了，我们可以看到出现了五花八门的压测平台，也会有后端监控数据的曲线，乍看起来，就两个字：全面！
可是，同样也没有告诉你瓶颈在哪里。
如果选择合适自己的工具？所以我们用工具，一定要知道几点：
工具能做什么？
工具不能做什么？
我们用工具的目标是什么？
当工具达不到目标时，我们怎么办？
把这几个问题在用工具之前就想清楚，才是个成熟的测试工程师，有这样的工程师的团队，才是成熟的性能测试团队（当然，成熟的测试团队还要有其他的技术）。
对企业，举例来说：
如果是一个需要支持万级、亿级 TPS 的电商网站，本身就是云基础架构，那么可能最简单的就是直接买这家的云压测工具就好了。
这样做的优点是不用再买机器做压力了。压力发起，主要就是靠压力机的量堆出来大并发。
但缺点也很明显，一是不能长期使用，长期用，费用就高了。二是数据也只能自己保存比对，如果测试和版本跨度大，还是要自己比对，无法自动比对。最后一个缺点就是 压力机不受控了。
所以如果有这样需求的企业，也基本上可以自己开发一套云压测工具了，从使用周期和长远的成本上来看，自已开发，都是最划算的。
如果是一个需要支持每秒 100TPS 的企业内部业务系统，就完全没必要买什么云服务了，自己找一台 4C8G 的机器，可能就压得够了。
这样的话完全可控，压测结果数据也都可以随时查看，可以留存。
如果是一个需要支持万级 TPS，但又不能用云服务的事业单位或政企，比如，军工业，那只能自己搭建一套测试环境了。这样做的优点是完全内部可控，数据非常安全，但缺点就是投入成本高。
对私企来说，开源永远是最好的选择，成本低，但是需要相关人员能力稍强一些，因为没有技术支持。
对政企和事业单位来说，收费是一个好的选择，因为有第三方服务可以叫过来随时支持。
对一个做短平快项目的企业来说，云服务会是一个好选择，成本低，不用长期维护数据。
对想做百年老店的企业来说，肯定是自己开发平台，尽量不选择云服务，因为技术是需要积累的。
对个人来说呢，不用举例，压测工具市场，现在肯定是首选学习 JMeter，其次是 LoadRunner。
JMeter 的势头已经很明显了，并且功能在慢慢扩展。开源免费是巨大的优势。
而 LoadRunner，不管它的市场现在有多凋零，它仍然是性能测试市场上，功能最为齐全的工具，没有之一。
总结总体来说，性能测试工具的市场中，可以说现在的工具已经种类繁多了，并且各有优点。在项目中，根据具体的实施成本及企业中的规划，选择一个最适合的就可以了。也可以用它们来组建自己的平台。但是请注意， 不要觉得做平台可以解决性能测试的问题，其实平台只是解决了人工的成本。
如果单纯为了追潮流而把性能测试工具的使用成本升得特别高，那就不划算了。
思考题今天的内容有点多，我提几个思考题，你就当是对文章的回顾吧。
你觉得企业选择性能工具应该考虑哪些方面呢？以及性能测试工具中是否必须做监控呢？
欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 25

提建议

03丨性能综述：怎么理解TPS、QPS、RT、吞吐量这些性能指标？

05丨指标关系：你知道并发用户数应该怎么算吗？

 写留言

精选留言(54)

zuozewei
2019-12-23
第一个问题：大概会考虑怎么几个方面： - 学习成本：对人员的水平要求，培训时间成本等； - 脚本编写：能否录制测试脚本，是否支持GUI操作等； - 安装部署成本：是否支持一键安装，是否支持docker等； - 是否免费：开源工具一般都是免费的；但是很多收费工具也的确物有所值； - 是否支持多协议：比如是否支持 HTTP 协议、RPC 协议等等 - 测试场景：是否有链路、场景编排管理，支持支持将请求编排成业务场景，即常见的一串联场景； - 流量控制：支持纵向的，上下游链路的请求量逐渐减少，整体呈现一个漏斗模型；也可以是横向的； - 压力控制：指压测时并发用户数、 TPS 的控制等； - 数据驱动：大量的测试数据的参数化； - 分布式支持：支持压力机集群； - 测试报告：压测结果是否能够图形化展示，提供美观且丰富的测试报告； - 二次开发的成本：由于时间或人力关系，也需要考虑二次开发成本； - 性能开销：执行机开销、软件可靠性、执行效率、业务处理能力等。 .... 第二个问题：我觉得一个好的监控系统大概需要包括以下几个方面： - 全栈系统监控是前提； - 关注于整体应用的 SLA：主要从为用户服务的 API 来监控整个系统； - 关联指标聚合：把有关联的系统及其指标聚合展示。主要是三层系统数据：基础层、平台中间件层和应用层。并提供一个全局的系统运行数据大盘，帮助快速找到系统瓶颈。 - 快速故障定位：快速定位问题需要对整个分布式系统做一个用户请求跟踪的 trace。只有做到了上述的这些关键点才能是一个好的监控系统，而显然目前的测试工具监控是不满足的。另外测试工具本身在做监控也有其局限性，如 jmeter 在压测量较大的情况下回传测试结果 Master 节点会成为容易成为瓶颈。
展开
作者回复: 嗯，你说的很对。我竟没有啥子可以补充的。
共 4 条评论
91
calm
2019-12-24
高老师，能否推荐一些性能测试这方面的书籍？
作者回复: 这个就比较麻烦了。除了写性能测试工具之外，性能测试基本上没有自己的书籍。但是写工具也不算是完整的性能测试。如果你要看的话，我建议你这样开。 OS、DB、存储、语言（java、go、python)、架构等各找一本性能相关的书看。比如说linux性能优化、java性能优化、mysql性能优化，这类的书。
24
私人领域
2019-12-24
现在在公司做的还是不太顺利，概念不理解，大家对并发的不理解，这包括开发，产品，项目，部分运维可以理解；还有就是无理要求要求8000并发，这个怎么跟他们解释都无用，一说就是客户要求的，这8000并发发包出去就几g的流量了，真不明白他们怎么想的，这做技术的人一点基础都没有，真的很难工作
作者回复: 要是你职位高，可以强势一点沟通。如果从历史数据中算到并发度并不高。（就是拿当前的用户和业务的TPS做比对就可以知道并发度。）那完全可以算得出来。现在不懂技术的人说的并发，大部分是说的在线。之前我算过一个要支持1000万基础用户（也就是数据库里总共只有1000万用户），再计算到日活，再计算到时、分、秒，才需要200TPS。
共 5 条评论
13
村夫
2019-12-24
老师请教一个问题。关于事物的定义，假如有一个兑奖的活动，进去活动页面会请求三个接口，一个个人积分接口，一个是任务列表接口，还有一个是兑奖列表接口。在页面点击兑奖按钮会去请求兑奖接口，兑奖成功页面会去调用用户接口刷新用户当前积分。这样的情况应该怎么去定义事物？
作者回复: 这就是之前的一个文中所写的。事务的定义取决于测试的目的： 1. 如果你想测试的是单个接口的容量，那显然，一个接口一个事务，并且都是直接连接口就行了。但是要注意的是，其实在测试兑奖接口的时候，后面的几个接口也都会调到，所以这时会把后面几个接口都压了。这时，如果你的目标只是测试兑奖接口本身，并不想测试关联的其他接口，那就mock掉。 2. 如果你要测试的兑奖的这个流程，那显然是从兑奖接口进去。事务定义到兑奖整个流程上。
11
小老鼠
2019-12-24
要测试一个在线运行的网站性能，应该使用什工具比较好？设置的被测网站的IP地址可以是公网IP吗？
作者回复: 使用什么工具取决于什么样的工具最适合应用场景。如果是HTTP协议的，那有很多工具都适用。没有谁比谁更好，只有哪个应用在团队中成本最低。关于压力工具我从来不纠结，就算自己写一个多线程工具也无所谓，只要能让我看到TPS、响应时间、错误率之类的数据就可以。从技术上说，不管是公网IP、内网IP，对性能测试的过程来说都无所谓，只要路由可达就可以测试。只是用公网IP要考虑出口流量，以及架构上的各种网络设备，像WAF、SLB、广域网设备等。并且如果是按流量付费的带宽，还要先计算下费用。还有客户端如果也在公网上，还要考虑客户端的出口带宽。但是这些都和性能测试技术本身无关。
6
Geek_081377
2019-12-24
支持高老师，希望听完能成为公司的性能大牛，哈哈
作者回复: 要是完全能在工作中落地的话，那就不是大牛了，是猛牛。哈。
共 2 条评论
5
律飛
2019-12-23
第一个问题：企业选择性能测试工具无外乎两种策略，一是性价比优先，花最少的钱最快地完成最多最需要完成的任务，比如租用云压测平台，属于头痛医头，脚疼医脚的临时策略，小公司、发展初期公司等常采用的策略，可以快准稳完成压力测试。二是结合长期发展目标，分阶段规划测试工具购买及测试人员培养，甚至自己开发测试工具，积累并形成自己的压测能力。这个策略与公司测试人员以及测试团队能力也有很大的相关性。其实老师已经讲得很清楚了。第二个问题，我个人认为不应该在测试工具中做监控。现在处于一个分工很细的世界，术业有专攻，专业人做专业事，一来可以保持工具的简洁，二来可以保持工具的通用性，增加使用的灵活性。当然这对做性能测试的人的能力要求就更高了。不过工作的乐趣不就在于此吗？
展开
作者回复: 理解的非常到位。完全领会了精髓。
5
罗辑思维
2020-04-05
最近在得到学习《薄世宁·医学通识50讲》 08丨病与症：为什么这些“病”不用治？文中对病与症的解读，让我能理解工具，性能指标，性能分析人员之间的关系。比如风寒感冒（症状是怕冷，流稀鼻涕），吃风寒感冒颗粒，热水泡脚。风热感冒（症状是咽喉肿痛，发烧），吃退烧片，热水泡脚，多喝淡盐水。对应性能分析性能指标 <---> 症性能分析者的判断 <---> 病性能优化 <---> 药而工具只是观察性能指标（症）的手段，就像医生用仪器测量血压。
展开
作者回复: 理解的很是合理。
共 2 条评论
4
小呀么小二郎
2020-03-12
思考题：你觉得企业选择性能工具应该考虑哪些方面呢？ 1、企业规模及性质 2、系统性能目标（想要支持多少TPS） 3、系统架构 4、员工的学习成本 5、工具的优势是否满足要求，工具的缺点是否对性能测试没有影响或影响不大（感觉自己的思维还是不够开阔呀，需要继续努力）性能测试工具中是否必须做监控呢？ 1、如果压测工具中必须做监控，那么大概率也就不会有监控工具了吧。因此监控工具的存在本身就表示了压测工具做监控这件事儿不是必须的。 2、第二点就是文中说的，数据流向不同，不符合真实的场景。本文虽然是讲工具，但并非单纯的讲工具。老师不断强调的一个点都是，性能测试一个完整的流程是测试验证、分析和调优。（可能是有太多人以为性能测试=会工具的使用吧）性能测试工具，本质上还是个工具，工具都是人发明的，为的是解决某个问题，同时都有自己的优势和不足。比如交通工具，上班的时候可以选择步行、骑自行车、骑电动车、开车、坐公交、坐地铁等等，开车肯定是最舒服的，但是可能会堵车；骑自行车是最健康的，但是耗时会长一些而且还要风吹日晒。其实选哪个都可以，只要能到公司就行。但是每个人的向往、喜好和财力不同，比如有人不怕日晒雨淋，更向往健康的生活方式，那我就选择骑自行车上班；有人讨厌堵在路上的感觉，所以选择地铁出行；有人没钱，买不起车，那就只能选择相对便宜的交通工具。因此，不用过分纠结用哪个性能测试工具，只要我们能拿到需要的数据就行。
展开
作者回复: 理解的很对。这样认真的话，我觉得看完专栏就是高手。
4
要不要菜
2020-03-16
说的太对了，目前就是到了尴尬的第三个阶段，会用工具会执行场景，就是不会分析调优
作者回复: 数据都看得懂，就是连不起来的感觉对不对？哈。那就来着了。
共 2 条评论
2
slark
2020-01-07
Jmete和Locust都学过，J感觉有GUI，L是Python，编写测试脚本更便捷
作者回复: 喜欢什么用什么。只要压力能发起来就行了。
2
月亮和六便士
2019-12-24
高老师，推荐几款监控Java语言接口和方法执行时间的工具，比响应时间细分到Java某个工程的jar包，我怎么监控这个jar包里的接口执行时间，方法执行时间，还有算法执行效率，等等
作者回复: 这有很多呀。像jvisualvm/jmc/arthus/btrace......。开源免费。
共 2 条评论
2
piboye
2021-05-08
jmeter对go开发者不友好，go的程序比较容易改和扩展，部署也方便，性能也强很多，老师可以推荐一款golang的性能测试工具不？
作者回复: 工具嘛，自行搜索一下吧。
共 2 条评论
1
一步
2020-12-28
对性能测试工程师的职责有了清晰的认知
作者回复: 这样的认识就是我想达到的效果呀。
1
莫西 👫 小妞儿 ...
2020-01-15
老师，想问一下前端性能的测试工作都有哪些呢？比如想知道实际用户看到页面中所有元素都加载完的时间
作者回复: 每个浏览器都有开发者工具。
1
莫西 👫 小妞儿 ...
2020-01-14
老师，我们单位属于国企，现在是用jmeter来压测，用nomn作为监控工具，这样是否可行。或者有什么更好的推荐么？
作者回复: 无所谓用什么样的工具，只要看到想看的数据即可。
共 2 条评论
1
Geek_0849d2
2020-01-07
什么样的业务可以线上直接压测，什么样的业务不可以？如何控制线上的性能测试？我遇到的项目都不能直接压测线上，直接线上压测，万一压塌了，影响正常用户使用怎么办？
作者回复: 在线下准备不出来足够的硬件设备。业务又很重要的。只能在线上做了。线上肯定会控制容量，不影响正常用户。
共 2 条评论
1
Geek_alair俊
2019-12-29
工具只是工具，通过工具的使用，分析出性能瓶颈，并且给出解决方案，这才是王道！神马各种压测工具，监控工具，看得见的没多少价值，分析这部分看不见的过程才是最有价值的！高老师一语中的。
作者回复: 多谢支持。希望理念传递给更多人。
1
苦行僧
2019-12-23
我们单位基本用jemter来压测，主要的测试为接口级测试，接口基本为数据给出接口，属于查询类事务
作者回复: 测试目标如果明确，怎么实现都是阔以滴。
1
Geek_615688
2022-07-06 来自北京
我看到这里，说压测都是用TPS来计算，为啥我们每次要压测，都是QPS计算，比如上次压测，研发说我期望你们压到1000QPS
作者回复: 我不建议用QPS这个描述，我更习惯用TPS这个描述。不过没有关系，只要说出来所有人都能理解是什么即可。

