智能客服高并发压测实战：工具选型、瓶颈定位与优化方案

做智能客服系统的性能测试最怕的不是发现性能差而是压测做完了一堆数据摆在面前却说不清楚瓶颈到底在哪。我最近刚带完一个客服机器人项目的高并发压测从工具选型到线上问题排查整个过程踩了不少坑也沉淀了一些比较实用的思路。这篇文章就当是一次复盘把整个流程从工具选型到优化方案完整梳理一遍正在搞客服系统压测的朋友可以少走点弯路。1. 先搞清楚智能客服的性能特征再谈压测1.1 智能客服不是普通Web应用压测思路必须变很多人一上来就按照传统Web项目的思路去压客服系统这是最典型的误区。智能客服系统的调用链比普通接口长得多一次用户提问从前端接入到语义理解、意图识别、知识库检索、答案生成中间可能经过四五个微服务而且还牵扯到外部依赖比如数据库、缓存、搜索引擎、甚至大模型接口。我这次面对的这套客服系统核心链路大概是这样的用户消息先进网关然后到会话管理服务再转发给NLP服务做意图识别和实体抽取接着查知识库或者触发FAQ匹配最后生成回复返回给用户。如果知识库命不中还会转人工或者走异步工单。这种链路带来的直接问题就是你不能只盯着某一个接口的TPS去压。比如你只压NLP服务的接口压出每秒2000的吞吐看起来很漂亮但真实场景下用户的消息是各不相同的缓存命中率、知识库查询复杂度、甚至网络抖动都会让实际表现大打折扣。所以做客服系统压测第一步就是要把整条链路画出来明确哪些是核心路径哪些是旁路旁路要不要纳入压测范围。还有一点容易被忽略智能客服有状态。普通的查询接口大多是无状态的但客服系统涉及到多轮对话会话状态得存住。这就导致压测的时候请求之间不是完全独立的上下文传递、会话续接、超时清理这些逻辑都会被触发。我在设计压测脚本时专门为“带会话上下文的多轮对话”这种场景单独造了一组测试数据效果比全用单轮对话压出来的数据更有参考价值。1.2 性能指标不能只盯QPS这几个数据才是关键传统Web压测大家习惯性看QPS、平均响应时间、错误率这三个指标。但放在智能客服场景里这几个指标远远不够至少要再加上几个客服场景特有的。第一个是首字延迟。客服机器人的体验用户反馈最敏感的就是“我说完话到它开始回复”的间隔。如果是流式输出就是字一个一个蹦出来的那种首字延迟比整体响应时间更能反映体感。我在压测时用了个简单方法客户端记录发出请求到收到第一个字符的时间差这个值在高峰期如果超过3秒用户的聊天框就会显得很“卡”团队会收到大量投诉。第二个是会话级成功率。单条消息的成功率好统计但一个会话里面连续3条消息都成功和3条里有1条失败用户的体感差距很大。我看数据的时候会把单条消息成功率与会话级成功率分开算。举个例子单条成功率是99%看着不错但假设一个会话平均有6条消息那整个会话完整走完的成功率大概是0.99的6次方只有94%左右意味着每100个用户里差不多有6个人聊着聊着就断了。这个数字如果不拆出来看特别容易错过真实体验问题。第三个是依赖资源水位。客服系统的瓶颈往往不在应用代码而在共用依赖。比如知识库用的ES集群可能同时给搜索业务在用MySQL里存了会话历史可能和其他报表业务共用实例。压测的时候必须同步观察这些基础设施的CPU、连接数、慢查询数否则你压测压出来的瓶颈根本不是自己系统的瓶颈。我当时在压测方案里就明确了一个原则数据必须分三层看第一层是入口层吞吐和响应时间第二层是核心微服务的耗时分布第三层是基础设施资源水位。任何单层数据都不能单独用来做扩容决策。2. 压测工具选型跟着场景选别跟着名气选2.1 主流压测工具的真实对比优缺点一次说清项目启动时团队内部先就压测工具吵了一轮。有说直接用JMeter的毕竟老牌、资料多有说用Locust的理由是脚本用Python写团队上手快还有人提议k6说轻量、支持云原生。我把四款主流工具各自跑了一轮对比demo最后选了k6但选它的过程值得展开说说。先说说JMeter。它的最大优势是生态成熟几乎什么协议都能压插件也丰富像后端监听器、实时结果聚合这些功能很实用。但痛点也很明显脚本是XML结构复杂场景写起来特别啰嗦。我想要模拟不同用户类型比如新用户首聊、老用户追问、VIP用户优先队列JMeter里要搞一堆逻辑控制器和用户参数配置维护成本高。再加上JMeter压高并发时单机施压能力受限于JVM堆内存3000并发以上往往需要分布式部署配置麻烦。Locust的脚本确实好写Python代码天然适合表达复杂业务逻辑。但Locust的默认IO模型决定了它对响应时间模拟偏乐观因为它用的是协程而非真实线程等待响应时并不占用真正的系统资源。这在低并发下没区别到高并发压测时它压出来的最大吞吐值会比真实值虚高一些容易误导容量判断。当然可以调参数去贴近真实但调起来繁琐团队几个人对协程模型的理解不一致争论成本太高。wrk属于轻量级利器单机能压出很高的请求量但它只能做HTTP层的压测场景表达能力基本为零。路由到不同URL、携带动态Token、检查响应内容里的业务码这些需求在wrk里实现非常别扭。智能客服的压测要模拟复杂的对话流程wrk不适合当主力工具。k6是后来选中的方案。脚本用JavaScript写语法简洁表达多轮对话、条件分支、动态参数都比较顺手。它用Go实现施压引擎理论上单实例能跑几万并发我实测在一台4核8G的云主机上压5000并发没遇到瓶颈。它的内置指标输出也很全http_req_duration、http_req_failed、自定义速率这些开箱即用。最关键的一点官方提供Cloud服务但开源版也能本地跑数据不落第三方适合企业内部项目的数据安全要求。2.2 选型不能只看功能这三个隐性成本必须算进去工具功能对比谁都做得到但真正影响落地的往往是隐性成本。我在这次选型中总结了三个维度建议你选型时也按这个思路过一遍。第一个是脚本语言与团队技术栈的匹配度。我们团队平时写业务代码以Java和JavaScript为主Python会一点但不精通。如果选Locust意味着要专门维护一套Python压测脚本后续加场景都得会Python的人来改这明摆着给自己埋坑。k6的JavaScript门槛几乎为零前端后端的人都能快速上手改脚本协作效率提升明显。第二个是测试数据的可编程性。智能客服压测最大的工作量不是压测本身而是测试数据的准备。你要模拟10000个不同用户每个用户有不同画像、不同会话历史、不同问题类型这套数据用脚本动态生成和维护的难度直接决定了压测效率。JMeter里面想动态生成一批用户数据得靠BeanShell或者JSR223脚本维护起来非常痛苦。k6可以在脚本里写原生的JS函数来生成用户池、会话ID、随机问题库逻辑完全可控。第三个是CI集成的友好度。性能测试不应该只在大版本发布前做一次而是每次核心链路有改动时都要快速跑一轮冒烟级的压测。k6可以很方便地打包成Docker镜像在CI流水线里拉起一个job跑完自动产出JSON报告并归档这个过程JMeter做起来要费好几倍功夫。真正落地之后我发现这个能力反而成了高频使用率最高的部分。最终我的结论是不是k6比其他工具“强”而是它最适合这个项目和团队。做技术选型最忌讳的就是别人说什么好用就上什么一定要把自身场景列清楚再拍板。3. 压测方案设计场景拆解和参数计算是重头戏3.1 三类压测场景覆盖日常与极端情况工具选完接下来最核心的工作是设计压测场景。我把整个智能客服的压测拆成三个维度的场景每个场景有不同的施压方式和目标指标压测报告也是按这三类分别输出。第一类是容量测试场景目的是摸清系统当前的性能上限。做法是逐步加压比如从200并发起步每次增加200每档持续跑3分钟观察吞吐量、响应时间、错误率随并发升高的变化曲线。这个场景要能回答一个问题当前配置下系统最多支撑多少并发在线会话且平均响应时间保持在2秒以内。第二类是稳定性测试场景目的是验证系统在持续高水位流量下的表现。做法是以容量测试结果的70%-80%作为目标并发持续压测不少于2小时观察有没有内存泄漏、连接池耗尽、GC恶化、日志堆积这类问题。智能客服系统常年在线半夜也会有人发消息稳定性测试的结果直接决定了能不能安心上生产。第三类是突发流量场景模拟的是搞活动或故障恢复时的流量激增。比如平时平均2000并发做活动瞬间冲到6000并发系统要有能力扛住这种冲击而不发生雪崩。做法有两种一种是从低并发快速拉升到超高并发的瞬时压测另一种是在高并发持续过程中额外叠加脉冲式的流量。后者更接近真实世界压测脚本里可以通过调整并发上下限来模拟脉冲。在时间安排上我把容量测试放在项目中期稳定性测试放在临近发布前突发流量测试则在稳定性测试通过后再跑。三类场景顺序严格固定因为容量测试的结果直接影响稳定性测试的压测水位取值稳定性不通过又说明系统还不能承受突发流量贸然去跑突发场景只会浪费排查时间。3.2 压测数据的生成逻辑决定了结果可不可信客服系统压测有个很大的坑数据太规整压出来的结果失真。如果你只准备一百条话术反复循环发到后面命中知识库的全是热数据缓存命中率几乎100%磁盘IO几乎为零这个结果好看但没用。真实用户的问题千奇百怪知识库的查询分布是长尾的。我在脚本里设计了一套数据生成策略。用户池按画像拆成几类新用户首次进入会话、老用户有历史会话记录、高频用户每天会发起多次会话、异常用户常发送语音转文字后带噪声的长文本。对话内容异步生成保证消息内容在词库范围内随机组合。比如问候语、业务咨询、投诉类、退款类、闲聊每种类型按真实业务占比设置权重而不是平均分配。这样做之后缓存命中率会趋于合理压测结果更能反映生产环境的真实表现。还有一个细节是会话ID的生成策略。压测时每个用户需要绑定稳定的会话ID这样会话状态才能跨请求保持。我用用户ID加随机种子来生成会话ID保证同一个用户的多轮对话走同一条会话链路但又避免不同用户的会话ID冲突导致状态串线。参数化这块我用的策略也比较粗糙但有效把数据和脚本分离动态数据放在外部JSON文件里脚本运行时加载并做随机采样。这样做的好处是调优时只需要改数据文件不用动脚本团队里不熟悉代码的人也能参与数据维护。3.3 目标指标的量级估算把业务预期翻译成技术参数压测前一定要先想清楚目标是多少而不是压完再说。目标指标需要从业务预期倒推我做了简单的估算公式供你参考。假设智能化服务要承担每日8万通会话且设定高峰期集中在每天两个时段总共约4小时。8万除以4小时是每小时2万会话换算成每秒大概是5.5个新会话。但客服性能压测不能只看新会话速率每个会话内部有多条消息交互假设平均每个会话有6条消息那每秒消息数大概是5.5乘6约33条每秒。再加上响应过程中产生的异步回调、状态上报等旁路流量我通常会在这个基础之上乘以1.5到2的安全系数。算出来60-70的消息QPS只是业务平均水位并不是压测目标。真正的压测目标取的是峰值冗余。按行业常见的1倍峰值冗余来看我把压测目标定在平均值的2-3倍也就是每秒150-200条消息稳定处理能力P95响应时间小于2秒。这样系统在搞活动、故障恢复、舆情爆发等极端场景下依然能扛住。容量测试结果达标与否都拿这几个数字作为判据。背后这个估算逻辑比具体数字更有参考价值——你可以根据自己的业务量套公式算一遍重点是要把平均数据换算成峰值吞吐再换算成真实链路消息量最后乘以冗余系数才能得到有说服力的压测指标。4. 高并发压测执行实录从脚本到分布式压测集群4.1 单机压不动怎么办分布式压测的第一步不是堆机器我们压测目标并发是6000在线会话经过容量测试之后发现需要拉升到8000左右才能摸到系统的真实瓶颈。单机跑这个量级已经不太现实了k6的单机能力再强单台普通云主机跑8000并发也会出现施压端自身的瓶颈比如端口耗尽、CPU跑满。这时候就轮到分布式压测上场了。许多人想到的第一件事是去买几台高配机器但我的建议是先把单机的压力模型跑准确再考虑扩展施压端。分布式压测最大的问题是时间不同步和数据聚合。如果施压节点都跑在相同配置的机器上网络延迟基本一致时间偏差可以控制在可接受范围。但如果节点分布在不同机房或者一边是云主机一边是物理机延迟差异会直接污染延迟统计结果出来的报告根本没法看。我用的是k6官方支持的k6-operator方案在测试环境里部署了一个小型K8s集群。压测脚本打镜像通过operator拉起若干个job实例每个实例平均分担目标并发。这个方案的好处是弹性伸缩方便不够用就加实例压完自动释放不会一直占着资源。要是没有K8s环境退而求其次的做法是用多台裸机分别跑k6然后手动聚合结果但聚合时务必保证每台机器的起始时间对齐不然很容易出现时间偏移误差。分布式压测的运行细节上有两点值得特别留意。第一是压测机所在网络与目标系统的网络延迟不能太高否则压测机到系统的链路就成了瓶颈测出来的吞吐量比真实环境低这个锅不该让被测系统背。第二是压测机之间的流量要均衡理想状态下每台压测机承担的并发差不多结果才具有参考性。4.2 压测执行时的监控大盘别等压完了再看数据很多团队的压测习惯是跑完一组压力把报告导出来再分析问题。我强烈不建议这样。压测执行的时候必须配合实时监控而且要分三个层面同时看。应用层面要看核心链路服务的CPU、内存、线程池、GC耗时、接口平均耗时和P99耗时。中间件层面要看MySQL的慢查询数、活跃连接数、锁等待情况Redis的命中率、内存使用率、慢命令数ES的查询QPS和熔断次数。基础设施层面看入带宽、出带宽、TCP连接数有没有打满。我用的监控组合是Prometheus加Grafana服务指标通过micrometer暴露中间件指标用官方exporter采集。压测前先花半天时间把仪表盘搭好把关键指标都放到同一页面上压测过程中就一直盯着这几个页面。方便起见我把监控也分享给团队所有参与者这样NLP组的同学看到自己的服务CPU涨得异常会主动反馈是不是知识库的查询逻辑出了性能问题不用等压测完再拉会复盘。有一个很典型的案例压测到3000并发时网关服务CPU只到40%但TPS却上不去了。从应用指标看一切正常但Redis的慢命令数飙升一查发现是某个高频访问的key用了大集合类型查询复杂度是O(n)并发一高就出现慢命令。这个如果没有实时监控Redis指标光看应用层数据根本定位不到压测完了也只会得出一个“网关性能莫名到顶”的错误结论。4.3 压测完的第一件事把报告解读成行动项压测产生一堆数据最终必须落成行动项才算有价值。我的解读逻辑很简单先确认数据有效性再区分性能瓶颈层最后按优先级队列排优化动作。数据有效性检查是第一步。如果压测过程中有大量请求因为压测机自身资源不足而超时这组数据就必须丢弃不能拿来分析。怎么判断呢看压测机本身的CPU和网络有没有打满以及压测脚本里记录的错误类型是不是包含了连接超时或写入超时这类施压端错误。确认数据有效后按层定位瓶颈。入口网关层瓶颈通常表现为CPU打满或线程池耗尽业务逻辑层瓶颈表现为某个服务响应时间特别长数据层瓶颈表现为数据库活跃连接数升高或者慢查询增加。每一层瓶颈对应不同的优化方向后面第五部分我会详细讲讲怎么针对每个瓶颈做优化。做完优化之后还有一件重要的事回归压测。优化完不能只跑一次就宣布完成至少要在同等条件下再跑一轮容量测试确认优化前后数据的对比。我习惯把优化前后的压测报告放在一起做对比分析响应时间下降多少、吞吐提升多少、哪一层水位明显降低这些数据直接推动了团队下一个迭代的排期优先级。5. 高并发优化的核心手段从应用代码到基础组件5.1 应用层优化缓存、批量、异步三板斧先说说最常见、也最容易见效的应用层优化。第一板斧是缓存优化。智能客服的知识库查询是典型的高频读操作如果每次请求都实时去查ES或者MySQL并发一高必崩。优化的核心思路是分层缓存第一层是本地进程内缓存第二层是Redis缓存第三层才是ES或MySQL。常见FAQ的高频命中热点问题直接放本地缓存就好命中率能达到60%以上数据库和ES的查询压力瞬间降下来。冷门知识走Redis缓存只有缓存未命中才打回源。同时要设置合理的过期策略和缓存更新机制避免缓存穿透和击穿。第二板斧是批量处理。客服系统里有很多适合批量操作的场景比如会话归档、消息写日志、情感分析结果落库。如果一个一个地写数据库或者调用外部分析接口性能极差。优化思路是把这些操作改成批量攒够一批再写。比如消息日志我调整为每攒100条或者每100毫秒刷一次数据库的写压力能降低一个数量级。这里需要注意积压时间不能太长否则日志延迟过大会影响排障。第三板斧是异步化。主链路里不是每一步都必须等结果回传给用户的。比如答案生成后要做质量评估记录、写用户行为分析、更新知识库点击率这些完全可以通过消息队列异步消费主线程只负责把答案返回给用户。我把这些旁路操作从同步改为异步之后接口的P95响应时间直接降了30%这个优化对体感提升立竿见影。5.2 中间件层优化连接池、线程池、队列积压一次说清应用层的三板斧做完之后接下来要处理的是中间件层面的瓶颈。最常见的问题是连接池配置不合理。Spring Boot默认的Tomcat最大线程数是200数据库连接池默认大小是10。当并发上来以后线程池先满请求排队数据库连接池后满数据库请求排队。这两个默认值放在高并发场景下都会成为瓶颈。我这次做的优化是分集群配置连接池。消息接入和NLP调用两个服务的线程池大小按峰值预期的1.5倍去配置数据库连接池大小与线程池大小匹配确保线程等待数据库连接的概率尽量低。连接池参数的调整不能拍脑袋要通过压测数据来校准。我的方法是在容量测试过程中逐步调大线程池和连接池同时观察响应时间曲线找到拐点。当响应时间开始明显增加的那一刻的前一个配置值就是比较合适的上限。连接池优化的具体操作是如果Tomcat线程池从200调到400响应时间有明显改善数据库连接池也要相应从10调到20或30但如果调到600响应时间反而变长说明瓶颈转移到其他层面了这时候就该停下来去检查是不是数据库慢查询或者锁竞争导致的。消息队列这块重点要检查的是消费者处理能力和队列积压情况。客服系统里有大量异步任务通过MQ解耦如果消费者处理能力跟不上生产者消息就会在队列里堆积表现为“接口响应正常但状态更新延迟严重”。优化方法是增加消费者实例数调整消费线程池大小或者把积压的消息做批量拉取处理。Redis这边也容易出问题。智能客服的会话状态、用户画像缓存、知识库Redis命中率低的时候回源数据库查询就会增加数据库负载瞬间升高。我的做法是给知识库的主要分类设置较长的过期时间给用户级缓存设置较短时间兼顾实时性和命中率。另外要特别留意Redis大key的问题某个已知问题的热搜关键词对应的知识节点如果特别大会变成热点KEY并发访问时存在单线程执行的瓶颈此时要做内容拆分成多个key分摊读写压力。5.3 数据层优化慢查询治理和分库分表的正确姿势客服系统的数据层会是多数场景的性能瓶颈。压测中我们发现大部分慢查询集中在会话历史记录和未读消息数统计这两个业务操作上。排查下来问题主要是两个一是会话记录表数据量过亿但是索引只有主键索引二是未读消息统计需要扫描某个用户的所有历史记录后做条件过滤查询性能随数据量线性下降。会话记录表的优化方案是增加联合索引把查询条件里的用户ID和时间范围两个字段一起建索引同时把历史数据按月做分区。优化后冷数据检索的耗时从平均2秒降到了100毫秒左右。这里想提醒一句加索引不是越多越好写多的表索引过多会导致写入性能下降压测时要确认索引优化对写入性能没有明显副作用。未读消息统计这类实时性要求高的操作不能实时去扫库而应该预计算或异步更新计数。我的方案是在Redis里维护未读消息计数每次新消息写入时同步更新计数读取未读数时直接查Redis这样数据库负载就降下来了。分库分表这事说实话不到数据量真的撑不住我建议不要轻易上。分库分表最大的成本是查询逻辑复杂度变高跨库查询和跨表分页会变得非常痛苦。在客服场景里如果会话记录表单表能控制在5000万以内加上合理的索引和归档策略性能完全够用不需要引入额外复杂度。真到了非分不可的时候也建议先做冷热分离把超过90天的会话历史归档到数仓或者冷存储线上保留热数据性能问题就解决一大半。6. 高频问题的定位思路一套可复用的排查路径6.1 高并发下常见的三类隐性故障压测过程中我们踩过的比较典型的问题有三类每类问题都有自己的排查路径值得单独拿出来说。第一类是连接池耗尽。现象是TPS先上升后突然掉到接近0错误率飙升日志里出现大量连接超时或获取连接失败的异常。排查路径是先确认是不是数据库连接池被打满方法是进入数据库看最大连接数和活跃连接数是否在同一量级如果是基本可以判定连接池耗尽。然后检查慢查询找出来哪些SQL在并发状态下变得异常慢导致连接长时间被占用。破解思路是优化慢查询合理调整连接池上限加缓存减少数据库访问频率。第二类是线程池耗尽或拒绝请求。现象是应用层接口的响应时间均匀地变长但CPU并不高错误日志里出现类似拒绝连接的异常。这通常是Tomcat线程池被打满请求都在排队等待线程。排查路径是先看线程池活跃线程数是否到了最大值再用jstack抓线程快照看看线程具体在等什么。如果是等数据库连接那就回到第一类的连接池问题上如果是等外部API响应那就要检查外部调用的超时设置是不是太长了。这类问题的通用解法是给外部调用设置合理的超时时间和降级策略而不是让请求无限等待。第三类是缓存穿透和击穿。现象是接口响应时间整体正常但偶发性地出现大量慢请求数据库活跃连接数在某个瞬间飙升。排查路径是看看慢请求的时间点与缓存过期的时间点是否重合如果是说明极有可能发生了缓存击穿。破解思路是热点数据缓存设置更长的过期时间可以使用互斥锁或单飞模式防止大量请求在缓存失效瞬间同时穿透到数据库。6.2 排查过程中的几个实用技巧排查故障时有些技巧能大幅提高效率。先说日志级别平时为了定位问题方便很多人把日志级别调到DEBUG这在高并发压测下会变成一场灾难。疯狂打日志会占满磁盘IO影响应用吞吐量。压测时把日志级别调到WARN以上必要的时候单独为链路追踪开启DEBUG不要全局开启。再说线程堆栈这是排查线上阻塞问题的神器。当接口响应时间异常时用jstack连续抓几份线程快照间隔5秒抓一份看线程卡在哪个调用栈上。如果多次快照都显示线程卡在同一个方法上那这个方法就是要排查的对象。我遇到过卡在Java的序列化方法上的案例。排查后发现是自定义序列化实现里加了一段同步锁在并发一高时锁竞争成了焦点。还有一个CPU飙高问题的排查技巧。当GC线程CPU占用很高时使用top -H找到CPU占用最高的线程再换算成十六进制线程ID在jstack的快照里定位到对应的线程状态。如果是GC线程那就需要加堆内存、调整GC策略、排查大对象分配频率了。如果是业务线程说明某个方法存在CPU密集计算需要从算法上优化或者加缓存。6.3 建立持续压测节奏让性能问题曝光在发布之前项目上线之后性能问题依然会出现不要以为做完一轮压测就万事大吉。开发迭代过程中新加的代码随时可能引入性能衰退比如一个查询不小心变成了全表扫描一个循环里不小心多了个远程调用。这些问题的共性是非常容易被忽略直到流量上来才暴露然后就得半夜爬起来紧急处理。我的做法是把压测接入到发布流水线里。每次核心链路相关的服务有变更CI流水线自动触发一轮轻量级压测跑5分钟结果与基准值对比超过阈值就自动拦截发布。这里说的阈值是多维度的除了响应时间还包括错误率、吞吐量以及数据库连接数和Redis命中率的相对变化。拦截之后自动通知开发人员查看原因。轻量级压测与完整压测不同不需要追求并发量的绝对高只需要保证覆盖核心链路的代表性场景并且结果可对比。自动化压测跑了一段时间后能积累一批历史基线数据后续每次性能优化和容量规划都有数据可用比凭经验拍脑袋靠谱得多。这套机制的收益是可持续的。在线上故障发生之前把大部分性能问题挡在发布流程外面比事后紧急扩容或回滚省力得多。我推荐的节奏是核心链路每次改动跑轻量压测每个大版本迭代跑一次完整容量压测每个月做一次稳定性压测。把压测当成日常习惯而不是上线前的临时抱佛脚这才是性能工程该有的样子。最后再分享一个压测中容易忽略但影响很大的细节压测数据一定要和真实数据分布保持一致。如果生产环境中用户输入的平均长度是30个字你的压测数据平均只有10个字那么NLP处理耗时和数据库查询耗时都会被低估。我的做法是拿生产环境脱敏的对话数据作为压测样本按真实场景切分和抽样保证压测压的是系统在真实环境下最可能出现的情况。这个细节做对了压测报告才真正有决策价值。