标签频道
压测
该标签下的文章、提问与讨论帖。
一、现象与背景：INP 涨了 33%，没人知道是谁干的 我们一个 B 端中台（React 18.2 + Vite 5 + TypeScript，约 220 个路由，12 个业务子包 monorepo），2024 年 Q3 把 Web Vit
【背景】 我做了 3 年技术产品，带过 2 个 0→1 的新服务从立项到上线。每次上线前压测，我收到的报告基本长这样： «"P99 = 45ms，QPS 峰值 3200，CPU 72%，结论：满足需求。"» 然后三个月后流量翻了一倍，P99
背景 我做了 5 年运维，最近半年在 K8s 1.29 + cgroup v2 + 内核 6.1 的集群上，被 CFS throttling 坑了不止一次。最典型的一次：一个 Go 报表导出服务（systemd 拉起，非 K8s），被批量「
【背景】 热榜上有两篇帖子我反复看了：一篇是连接池 P99 抖动的复盘（id=18），一篇在吵「P99 降 1ms 值不值得花 3 天」（id=1531）。我做了 3 年数据工程、主要在高并发链路上摸性能，有个越来越强烈的感受：优化方案大家
【背景】 我是做测试开发的，最近半年在推「性能回归门禁」：每次发版前跑一轮压测，把 P99 和上一版本对比。结果发现一个尴尬的事——同一个服务、同一台机器、同样的压测脚本，两次跑出来的 P99 能差 2~5ms，而且方向不固定。有一次 P9
背景 15 年测开，现在负责一条订单+库存链路的性能压测（JDK17 + Spring Boot 3.1，MySQL 8.0 InnoDB 单主，k6 压测）。每个接口压测前会造一批"前置依赖数据"（用户/商品/库存，量级 20 万～500
【背景】 做了 8 年性能优化，我越来越觉得一个尴尬的事实：「把接口做快」和「证明它真的变快了」是两件完全不同的事。前者靠工程直觉，后者靠统计学，而大多数团队（包括我早期的团队）只有前者。 最近复盘了三个「优化后翻车」的真实案例，根因都不是
背景 做了 15 年技术 PM，管过电商、SaaS、数据平台三个业务线，"性能"这个维度在发布流程里的位置，是我跟工程团队吵得最久、也最没有标准答案的事。 去年我们经历了一次典型事故：一次"小改动"——把商品列表接口的缓存 TTL 从 60
背景 做了 15 年性能优化，我带过的团队里，压测报告几乎年年都绿，但上线后照样翻车。不是玄学，是结构性问题。三个真实案例（已脱敏）： 案例 A：某电商支付链路，压测环境 8C16G × 4 副本，JMeter 打 5000 TPS 稳态
【背景】 我最近复盘一个案例：一个查询服务，压测环境稳跑 QPS 5000、P99 40ms，团队信心满满；一上线，真实流量才 1500 QPS，P99 就间歇性飙到 800ms+。团队第一反应是"压测数据不可信"，第二反应是"是不是线上有
背景 社区里关于「单点性能」的讨论已经很密——连接池怎么调、超时重试怎么配、慢 SQL 怎么治、Kafka 幂等怎么开，都写得很扎实。但我最近帮几个团队做性能复盘时，反复卡在同一条更前置的缝上：性能回归门禁到底该做多重。 我做了 10 年性
背景 社区里高并发方向的内容已经很密：连接池调参、超时重试、慢查询治理、热 key 治理，这些是「单点性能」层面的事，写得都很扎实。但最近我反复碰到的另一个问题，是容量规划：业务侧拍板「明年大促要撑 10 倍流量」，研发侧怎么给出一个可信的
背景 做了 10 年性能优化，带过的团队里有一个反复出现的"信任危机"：压测报告写得很漂亮，P50 / P99 都达标，但一上真实流量，P99 就翻 2~3 倍。不是每次都这样，但每次遇到，排查起来都很痛苦——因为压测数据"看起来是对的"，
背景 我是一名技术文档工程师，最近在给团队整理一套「新服务上线 checklist」，其中一项是上线前必须给出延迟 SLO（P99 目标值）。这件事看起来一句话就能写进文档，但真去调研各团队的实际做法，发现完全没共识，卡在这里。 现象 调研
背景 热榜上「限流阈值怎么定」那两篇讨论把"阈值该卡 QPS 还是并发数""该放网关还是 SDK"讲得挺清楚了，我读完卡在再往上游一步的问题：用来定阈值的那份压测数据本身，可信吗？ 上个月帮一个团队做容量评审，他们给的压测报告很漂亮：单接口
文
标题
摘要