企业官网建设流程全解析

简介：虫师编写的《Web性能测试--基础概念》是一份面向性能测试初学者的入门PDF，系统讲解Web性能测试的核心概念与完整实施思路，帮助读者从零建立知识体系。内容首先梳理性能测试四大分类：压力测试用于探测系统临界点，负载测试验证预期负载下的稳定性，稳定性测试关注长时间运行表现，竞态条件测试则排查多用户并发冲突；同时引入“理发店模式”解释并发用户的不同状态，并给出吞吐量、响应时间等关键指标的定义。第二部分详细展开性能测试完整流程：先问清需求、了解系统架构，再分析测试点、选择合适的工具（如JMeter、LoadRunner、Gatling等），随后编写测试计划、搭建与生产环境相似的测试环境，最后执行测试、收集性能数据、进行调优并输出包含分析与建议的测试报告，形成一套可落地的参考路线。资源为1个PDF文件，大小531KB，便于随时阅读；目前已有463人学习下载。对于刚接触性能测试的读者，这份PDF能帮助快速理解各环节要点、少走弯路，为开展真实负载测试和性能优化打下扎实基础。

1. 拿到任务先别急着压测：Web性能测试到底在测什么

第一次接到性能测试任务的场景，多半是领导甩过来一句“系统下周上线，你先压一下”，然后留下一脸茫然的你。这时候最怕的不是不懂工具，而是连「并发用户数」「吞吐量」「响应时间」这些基础概念都还没捋清，就开始在JMeter里乱填线程数——填少了测不出问题，填多了把环境打挂，最后报告里连结论都不敢写。这份PDF的价值就在这儿：它不教你某个工具的具体按钮，而是把Web性能测试里最容易混淆的分类、并发模型、指标含义，以及从需求确认到性能调优的完整八步思路，用一套能直接照做的流程讲清楚了。适合刚转性能方向的功能测试、被临时拉去顶岗的开发者，以及想系统补一遍基础概念的从业者。看之前建议先放下工具，把「测什么、怎么测、结果意味着什么」这三件事想明白。

2. 性能测试分类：压力、负载、并发测试真不是一回事

很多人写报告的时候，习惯把这次测试叫「压力测试」，下次换个场景又叫「并发测试」，名字换来换去，本质区别却说不上来。这一章的核心在于：分类不是用来抠字眼的，而是用来确定你要在什么条件下、观察什么指标、得出什么结论。

2.1 七类测试的关注点：从验证能力到找极限

原文档里整理了七种常见的性能测试类型，可以看作一张对照表：

这套分类最大的用途，是帮你从一开始就想清楚「这次测试的终点是什么」。比如要验证新系统能不能上线，走的是狭义性能测试路线，有明确的目标值，测完达标就结束；但如果要找出系统到底能扛多大压力，那就得走负载测试路线，加压加到指标超标或资源饱和为止。 我见过不少初学同学把负载测试和压力测试混着用，加压加到一半看到CPU满了就开始报「系统存在瓶颈」，但负载测试本来就是要压到极限的，CPU饱和是预期结果，不是缺陷，报告里写不清楚就闹笑话了。

2.2 爆发力、耐力与整体协调性：用运动员视角理解分类

分类表背下来容易，用起来难。原文档里用一个运动员的比喻把这件事讲得特别透彻：系统性能看的是「爆发力」「耐力」和「整体协调性」。爆发力对应系统能承受的最大压力，好比举重选手能举起多重，扛过三秒就算成功；耐力对应系统在长时间压力下的稳定性，好比马拉松选手，百米跑再快，四十公里坚持不下来也没用；整体协调性则对应系统有没有瓶颈，某个部件再强，有一个短板拖后腿，整体性能就上不去。

这个比喻对测试设计的指导意义很直接。做压力测试的时候，你会关注爆发力，压到系统扛不住为止，看它在极限状态下的表现；做可靠性测试的时候，你会关注耐力，加载一定压力之后让系统连续跑半天、一天，看内存和CPU的占用曲线有没有随时间上涨的异常趋势；而性能调优阶段，你会像教练分析运动员一样，重点盯「短板」——数据库连接池不够、磁盘I/O排队、某个接口的串行逻辑，往往是整体性能被拖垮的根源。

所以在实际做测试方案时，我一般会先按这个隐喻问自己三句话：这次要看系统扛多大的量（爆发力）？要看它能撑多久（耐力）？还是要找出哪个环节先撑不住（协调性）？答案直接决定了后面的压测场景怎么设计、跑多久、看哪些指标。

2.3 分类实战：一次完整回归里如何组合使用

分类的价值不在分类本身，而在组合使用。一个典型的性能回归过程，通常不是只跑一种测试，而是分阶段推进，每一步用不同的测试类型回答不同的问题：

• 先做并发测试：选两三个高频核心操作（比如登录、查询、提交），模拟多用户同时操作，先把死锁、线程锁、资源争用这类并发缺陷暴露出来。这个阶段通常跑短场景，几分钟一轮，重点是看有没有报错和异常。
• 再做负载测试：逐步增加虚拟用户数，每增加一档就维持几分钟观察指标，直到发现响应时间明显上升或吞吐量不再增长，由此描出一条「性能随负载变化」的曲线，找到系统能稳稳扛住的区间。
• 接着做压力测试：把负载推到极限，比负载测试再多压30%-50%，看系统在CPU和内存饱和状态下的表现，是优雅降级还是直接崩溃，错误率有多高，恢复后是否正常。
• 最后做可靠性测试：在系统能稳定处理的负载水平下，连续跑12小时甚至更久，重点盯内存占用趋势、连接池回收情况、GC频率这些容易随时间恶化的指标。

这样四个类型串下来，既覆盖了「会不会出并发问题」「能扛多少量」「极限在哪」「稳不稳定」四个维度，又避免了一次测试里什么都想测、什么都测不深的局面。

3. 并发用户与吞吐量：理发店模式里的两条边界线

并发和吞吐量是性能测试里被滥用得最厉害的两个词。很多人以为并发用户数就是系统用户数，以为吞吐量大就是处理能力强。但实际上，这两组概念中间隔了好几层换算关系，不明白这些，压测场景设计就是拍脑袋。

3.1 并发有两种：业务视角与服务器视角

并发这个说法本身就带着歧义。从用户操作的角度看，并发有两种：一种是严格意义上的并发，所有用户在同一时间点做同一件事，比如同一时刻全部做登录操作；另一种是广义范围的并发，多个用户同时发出请求，但这些请求可以是相同也可以是不同的操作，有人在登录，有人在提交表单，有人在查询数据。

可是从服务器的角度看，情况又不一样了。服务器处理每个请求都极短，每秒能处理几千几万次请求，所以它眼里的「并发能力」实际上是每秒能处理多少请求，而不是同时有多少人按下了按钮。原作者在这里做了一个很有意思的结论：真正意义上的并发不存在。因为即便性能测试工具一秒能模拟成千上万个请求，这些请求的产生也有先后顺序；即便同时生成，经过网络传输、带宽限制、延迟影响，到达服务器时也已经被打散了。再进一步说，服务器在处理这些请求时同样要排队分先后。

这个结论对测试工具的使用很有启发：你设了500个并发用户，工具并不会真的在同一微秒发出500个请求，它更像是按线程循环不停发请求，所谓的「并发」，是单位时间内的请求密集度，而不是「同一瞬间按下去」的动作。设计场景的时候，与其纠结「是不是真同时」，不如关心「每秒实际打到服务器多少请求量」。

3.2 理发店模式：最佳用户数与最大用户数的推导

原文档用理发店的比喻把并发用户讲得特别直观。一个理发店有三个理发师傅，每位师傅服务一个顾客需要一小时，顾客从进店起最多只能等待三小时。这个模型可以推演出两个关键数字：最佳用户数是3，因为3个用户正好让三位师傅满负荷工作，顾客到了就能服务，收入和满意度双高；最大用户数是9，因为在前三批顾客里，第1批3人正在被服务，第2批3人等待1小时，第3批3人等待2小时，等到第4批顾客来的时候已经等了3小时还没轮到，就会离开。也就是说，这个理发店在一个时间点上，最多能留住9个「有效顾客」。

这里有两个容易忽略的边界条件。一是等待超时的顾客不该计入最大用户数，因为他们已经走了；二是如果理发店的容量小于9，比如最多只能容纳6位顾客，那第7位顾客哪怕等2小时就能轮到——在他可接受的范围内——也会因为坐不下而流失。放到系统上完全对应：最佳用户数相当于系统不出现过载、资源充分利用的负载水平；最大用户数相当于还能勉强维持「不丢请求」的极限水位；而系统的容量（比如连接池上限、队列长度）则决定了实际能兜住多少人。

3.3 吞吐量与吞吐率：TPS、HPS该怎么看

吞吐量指一次测试过程中网络上传输的数据总量，但作者用了一个很关键的例子来说明它为什么不够用：一个水龙头开24小时流出10吨水，10个水龙头开1秒流出0.1吨水，按总量算是一个水龙头的吞吐量更大，但你能说一个水龙头的出水能力超过10个水龙头吗？不能。所以做性能分析时要看的是「吞吐率」——限定时间单位之后的数据量，通常是字节/秒、请求数/秒或页面数/秒。

再往下一层，吞吐率引出了事务和TPS的概念。事务是用户某一步或几步操作的集合，但必须保证它有完整意义，一次页面请求、一次登录、一次支付确认过程，都能看作一个事务。TPS就是每秒钟系统能处理的事务或交易数量，是衡量系统处理能力的核心指标。还有点击率（HPS），每秒钟用户向Web服务器提交的HTTP请求数，它更能体现用户端对服务器的压力，而TPS更能体现服务器对请求的处理能力。需要注意的是，一次鼠标单击可能向服务器发出多个HTTP请求，所以「点击率」里的点击不能等同于鼠标单击。

吞吐量指标有两个重要用途：一是协助设计测试场景，根据估算的吞吐量数据反推事务发生频率和次数，测试结束后也能用实际吞吐量衡量是否达到设计目标；二是协助分析性能瓶颈，有经验的方法会告诉你，80%的系统性能瓶颈都受吞吐量制约，通过不断增加并发用户数和吞吐量，从网络、数据库、应用服务器和代码四个环节去定位问题，比漫无目的地看指标要快得多。

3.4 用户数三层衰减：注册数、在线数、并发数

把这三个数搞混，是压测场景设计翻车的最常见原因。假设一个网站有20万注册用户，这是系统用户数；高峰时有2万人同时登录网站，在页面上挂着，这是同时在线人数。但这2万人并不意味着服务器同时承受2万并发请求——大部分用户打开页面后处于阅读状态，不发请求，某些时间点上真正在发请求的可能只有几百人。这三层关系可以用表格直观表示：

所以确定服务的最大并发访问数，正确做法是分析服务器日志，统计时间粒度高点的请求分布，看某个业务高峰期究竟每秒有多少个请求进来，而不是拿注册用户数去乘一个比例就完事。

4. 完整测试思路：从问清需求到性能调优的八步流程

知道概念只是第一步，真正考验人的是「拿到任务之后，一步步怎么走」。原文档给了八步流程：问清需求、了解架构、分析测试点、选择工具、编写计划、搭建环境、实施测试、性能调优。这套流程的价值在于，每一步都有明确的输入和产出，走完一遍，哪怕系统没测出什么问题，测试过程的专业度也已经到位了。

4.1 问清需求：识别四种测试目的的判断标准

接手性能测试任务的第一件事，不是打开工具，而是问清楚「这次测试的目的到底是什么」。原作者把常见目的分成了四类：新系统能力验证、客户有明确要求、找出系统瓶颈、稳定性验证。这四类的测试策略完全不同。新系统验证最简单，环境、压力点、工具选择都比较自由，只要测出达标就能交付；客户有明确要求也很好办，比如「同时满足100用户登录，平均登录时间不超过5秒」，目标值就在那里，测完对比即可；如果是找瓶颈，测试重点就要放在系统架构分析和业务分析上；如果是稳定性验证，关键就在测试时长上——内存泄漏这类问题通常要跑几个小时才会暴露出来。

值得注意的是，客户提的要求未必都合理，有些需求明显超出了当前硬件或架构的能力范围，这时候测试人员能做的就是把测试数据如实记录，至于「加硬件还是优化代码才能达标」，那不是测试的职责，不该擅自承诺。拿到需求时追问目的还有一个好处：能看出这次测试是走个过场还是认真要做，直接影响你投入的精力。

4.2 了解系统架构：画出请求的完整链路

不懂架构，环境搭建和性能分析都会卡壳。一个基本的Web系统架构分为三层：表示层、业务逻辑层、数据层。表示层就是浏览器端，通过HTML、JavaScript、CSS把功能和数据展示给用户，通过TCP/HTTP协议和业务层通信；业务逻辑层运行在应用服务器上，中间件作为容器承载应用，接收前端请求、调用数据层、组装结果返回；数据层运行在数据库主机上，通过JDBC等接口和应用通信，负责存储与查询。

实际项目里的架构通常有两种变形：一是水平拆分，把一个大而全的系统按业务拆成多个服务，比如交易服务、查询服务，各自独立部署；二是负载均衡，在入口处分散请求，让多台机器分担压力。原作者还给了一串常见的整体架构组合，比如Linux加Nginx加Redis加PHP加MySQL，或者Windows Server加Tomcat加Oracle加Java，Windows Server加IIS加C#/ASP.NET加SQL Server。这些组合决定了测试时要在哪一层加压、哪一层重点盯指标。 我通常在了解架构时会强制自己画一张请求链路图，标出「用户→负载均衡→应用服务器→缓存→数据库」的每个节点，后面所有分析和报告都挂在链路上说话。

4.3 分析测试点：按频率、关键程度、资源占用三维筛选

一个系统几十上百个功能，不可能每个都压一遍。测试点的选取有三个标准：发生频率非常高的，比如邮箱的登录、收发邮件，可能在每天业务总量里占到90%以上；关键程度非常高的，产品经理认为绝对不能出问题的，比如登录；资源占用非常严重的，比如某个业务提交时要向十几个表写数据，或者某个查询会检索大量数据记录。三个标准有重叠的，就是最优先的压测对象。

对性能需求点的描述要做到三件事：准确、一致、有条件。准确的意思是需求要量化到具体数字，「系统必须在不大于10秒的响应时间内处理20起登录任务」，而不是「登录要快」；一致的意思是用户、开发、测试对术语理解要一致，并发用户数、在线用户数、注册用户数不能各说各话；有条件的意思是性能需求必须限定在特定的数据量和运行条件下，比如「后台数据量10G、操作数据量20K、1500个用户、500个并发用户、连续运行12小时」，脱开条件的性能指标没有意义。

4.4 工具选型：商业、开源与自研的取舍边界

性能测试工具分三类：商业收费、开源免费、自主开发。选择时主要看四个方面：性能需求是否满足——系统协议不支持、模拟用户数达不到，或者要测流媒体这类特殊场景，工具再贵也不行；购买成本——正版商业工具的授权费用很高；人员学习成本——找个工具让团队学半年脚本，项目早就黄了；特殊需求——定制化程度高的场景可能需要自己写。原作者给的路线图很务实：最好熟悉一款商业工具、一款开源工具，再掌握常见的脚本开发语言，三者搭配基本能覆盖大部分需求场景。

4.5 计划、环境、实施、调优：从文档到落地的关键衔接

测试计划要写清楚被测对象和压力点。典型的压力点包括登录——用户操作系统的前提，游戏开新服时玩家挤破头也要登录；查询——最消耗系统和数据库资源的操作；交易——电商系统的速度直接决定用户是否转投其他平台。被测对象应该是最基本、使用最频繁的功能。压测环境的搭建有一条铁律：最好在独立的环境里做，不受到外界干扰，保证测试数据独立有效。

实施阶段我一般会这样操作：先跑一个冒烟脚本确认链路通了，再从预期的并发用户数的一半开始加压，每档维持3到5分钟，收集响应时间、TPS、CPU、内存、磁盘I/O、网络带宽的数据，然后逐步增加并发数，直到出现拐点或错误率超标。如果压的是服务器端的处理能力，测试机和被测系统必须放在同一局域网内，否则网络带宽和延迟会成为不可控变量。调优环节，常见做法是按「网络→数据库→应用服务器→代码」这个顺序排查，每换一个变量就重新压一轮，用单变量法确认到底是哪个环节改出了效果。采集服务器资源时，我一般会开三个终端并行记录：

# 终端1：实时看CPU和内存占用 top -b -d 2 > /tmp/top_$(date +%H%M).log # 终端2：每秒采一次CPU队列、内存、swap、I/O等待 vmstat 2 300 > /tmp/vmstat_$(date +%H%M).log # 终端3：采磁盘I/O，定位是不是磁盘吃了瓶颈 iostat -x 2 300 > /tmp/iostat_$(date +%H%M).log

这三条命令的含义分别是：top -b -d 2以批处理模式每2秒刷新一次CPU和内存快照，适合长时间记录；vmstat 2 300每2秒采样一次系统整体的运行队列和I/O状态，一共采300次，正好10分钟一轮，其中r列代表运行队列长度，wa列代表I/O等待占比；iostat -x 2 300每2秒输出一次扩展磁盘统计，%util接近100%说明磁盘基本饱和。这三个日志文件和压测工具的聚合报告放一起，就能把「压力从哪来、瓶颈在哪层」对应上。一边压测一边记录日志，测试结束后把时间戳对齐，判断系统瓶颈到底卡在CPU、内存还是磁盘上，比直接看一张平均响应时间曲线可靠得多。

5. 避坑指南：五个高频翻车场景的现象、原因与解法

这一章是踩着坑写出来的。下面五条，每条都是性能测试里真实出现过的问题，按「现象→原因→解决」梳理清楚，看完至少能避开一半的返工。

5.1 拿公网系统练压测，测完发现数据全废

现象：用性能测试工具直接对部署在公网的服务加压，跑完看报告，发现响应时间高得离谱，错误率也不低，但说不出到底是系统的问题还是网络的问题。

原因：公网的网络链路完全不可控。请求从测试机发出，经过多少跳路由、多少层带宽限制、多少延迟，都是未知变量。原作者说得更直白：就算你的请求都能成功发出，到目的地的时候，已经不能叫并发了。互联网是个网，就算相同的起点和终点，走的路线都可能不相同。在公网环境下测出来的响应时间，是「网络耗时+系统处理耗时」的混合体，完全无法剥离出系统真实的处理能力。

解决：性能测试优先在局域网内完成，且要保证网络的独立性。测试过程中路由器最好只服务测试设备，别让其他机器蹭带宽。测试机与被测服务器之间用千兆交换机直连，网络延迟基本可以忽略不计，响应时间的大头才是系统本身。

5.2 拿「注册用户数」当并发数，场景压力虚高一倍

现象：设计了500个并发用户，JMeter线程组里真填了500，压完发现系统已经快崩了，但你心里清楚这套系统平时根本没有那么大的流量，于是不确定是系统太差还是场景设错了。

原因：并发用户数不是系统用户数。20万注册用户、2万同时在线，真实落到某个时间点上的请求可能只有几百人。把最上层的用户数直接当并发数用，等于给系统加了远超实际的压力，测出来的结果根本不代表线上真实表现。

解决：并发规模从服务器日志里取。统计业务高峰期时间粒度数据（比如每分钟请求数），换算出一秒内的平均请求数，再用这个数去配置压测场景。没有日志的场景，先按估算流量的三分之一起步，逐步加压，观察系统表现再决定要不要继续往上加。

5.3 只看平均响应时间，被「美好的均值」骗了

现象：压测报告显示平均响应时间只有300毫秒，领导很满意，结果线上真实用户反馈「经常转圈转好久」，两边对不上。

原因：平均响应时间被长尾请求拉偏了。比如100个请求里90个是200毫秒，10个卡到2秒，平均值就只有380毫秒，看起来「挺好」，但那个2秒的体验已经是用户能感知到的卡顿。原作者在讲响应时间时专门强调过：整个响应过程要拆成呈现时间、数据传输时间、系统处理时间三段，前两段不是你能控制的，只有系统处理时间才是性能测试要验证的对象，但平均值的算法根本不体现这种分层。

解决：看分位数。JMeter聚合报告里，把响应时间按升序排列，取90%线、95%线、99%线，找出那批「拖后腿」的请求。分析时先看是不是某些接口和场景固定慢，再看是不是出现了线程阻塞。从那以后我压测报告里一定放两张图：一张平均响应时间随并发的变化，一张P95响应时间随并发的变化，两张图对不上，就说明有长尾问题，肯定不是简单加机器能解决的。

5.4 场景全放一个功能，混合场景缺失

现象：压测场景里100个用户全在操作同一个查询接口，测完性能「达标」，但上线后系统经常出现数据库连接池耗尽的问题。

原因：只压单个热点功能，忽略了不同操作对资源的竞争。线上是混合场景，有人在登录、有人在查询、有人在提交订单，不同类型的请求会互相争抢数据库连接、线程池、内存。单场景测试发现不了这种「挤兑」式的问题。

解决：压测场景按线上流量比例混编。比如从日志里统计出各接口的调用占比，登录占15%、查询占40%、提交占20%、浏览占25%，JMeter里就按这个比例配置不同线程组，每组跑自己的业务流程。并发测试的定义里本来就包含「广义并发」——同一时刻有人在登录有人在提交表单，混合场景才真正覆盖了原文说的「多用户同时访问同一个应用、同一个模块可能存在死锁或资源争用」的检查目标。

5.5 测试类型混为一谈，报告结论站不住

现象：明明做的是负载测试，压到某个点CPU到了90%，就在报告里写「系统存在性能瓶颈，CPU需要扩容」。评审时被问了一句「负载测试不就是加压找极限吗，CPU高不是预期吗」，当场答不上来。

原因：对测试类型的目标不够清晰。负载测试的终点本来就是找到极限——响应时间超过预定指标或资源饱和，CPU被压到90%恰恰是「找到了极限」这个目标实现的标志，不该把它当成缺陷来写。

解决：写报告前先给自己的测试定性。验证能力用性能测试，找极限用负载测试，看饱和状态下的稳定性用压力测试，验证长期运行用可靠性测试。每种类型的结论句式是不一样的：负载测试的结论是「系统在XX并发下到达拐点，建议容量按XX规划」，压力测试的结论是「系统在CPU/内存饱和状态下，错误率XX，表现稳定/不稳定」，性能测试的结论是「系统在XX条件下，响应时间XX毫秒，满足/不满足XX需求」。结论和测试类型对不上号，报告份量就轻了大半。

6. 进阶技巧：用三条曲线精确定位系统瓶颈

把概念捋清、流程走完，性能测试的工作其实还剩最后一公里：拿到一堆指标之后，怎么快速判断系统到底哪里不行。我自己的习惯是强制自己先画三条曲线，画完再开口说话。

第一条是吞吐量曲线——TPS随并发用户数的变化。这条曲线的典型形态是：一开始并发增加，TPS跟着线性上涨；到某个点之后，TPS增长速度放缓；再往后，随着并发继续增加，TPS不涨反跌。那个「不涨反跌」的转折点，就是系统处理能力的边界。值得注意的是一个被反复验证的经验规律：80%系统的性能瓶颈都受吞吐量制约，所以先看TPS曲线能帮你快速锁定问题的大方向。

第二条是响应时间曲线——平均响应时间和P95响应时间随并发用户数的变化。正常情况下，低并发时响应时间平稳，到达某个拐点后开始快速攀升。如果P95曲线的拐点远早于平均响应时间的拐点，说明系统里已经出现了明显的排队等待，某些请求被卡住了。这条曲线和TPS曲线配合起来看，能判断出系统是「安全地到达极限」还是「提前劣化」。

第三条是资源使用率曲线——CPU、内存、磁盘I/O、网络带宽的利用率随并发的变化。看这条曲线的目的，是把前两条曲线暴露出来的「系统不行」定位到「具体哪里不行」。CPU跑满而TPS不高，说明可能是应用代码里存在大量的CPU密集操作；磁盘I/O的%util接近100%，说明数据库的查询或写入效率出了问题；内存持续上涨且不知道什么时候释放，方向基本指向内存泄漏；带宽打满而CPU和磁盘都闲，说明瓶颈在网络链路或负载均衡层。

三条曲线对齐之后，再按「网络→数据库→应用服务器→代码」四个环节逐个排查变量，每改一处，重新压一轮，只看对应曲线的变化是否出现预期改善。这个过程听起来有点繁琐，实际操作时可以用一个简单的脚本来加速看数据——从压测工具导出的CSV响应时间日志里，直接算分位数，不用打开Excel一个个拉：

# 假设JMeter导出的是 CSV，第2列是响应时间毫秒 awk -F',' 'NR>1 {arr[NR]=$2} END { asort(arr); n=asort(arr); print "P50:", arr[int(n*0.50)]; print "P90:", arr[int(n*0.90)]; print "P95:", arr[int(n*0.95)]; print "P99:", arr[int(n*0.99)]; print "MAX:", arr[n] }' result.csv

这段awk做的事情是：跳过CSV的标题行，把第二列的响应时间值存进数组，全部读完后用asort排序，再按50%、90%、95%、99%的位置打印出对应的分位数值。NR>1是跳过第一行表头，arr[NR]=$2表示用行号做下标、取第二列的值，asort(arr)把数组按值升序排序，n=asort(arr)同时把排序后的数组长度赋给n，后面的int(n*0.95)就是95%位置的下标。跑完这行命令，你就能在一秒内判断出这轮压测里到底有多少请求被「尾部长尾」拖住了。

从那以后，我每次拿到压测结果，都强制自己先画这三条曲线再下结论。画完之后，很多原来要争论半天的问题，比如「系统还行不行」「该不该加机器」，答案基本已经摆在图上了。这套查看指标的思路是整个性能测试流程里最值得内化的一步——因为压测是手段，定位瓶颈、指导调优才是目的。希望帮到你。

本文还有配套的精品资源，点击获取