库存与抢购CASE 01
开票页面“快”到底要看哪些指标？
用户正在做什么
十万用户同时进入购票流程。
业务会出什么问题
平均响应时间可能很好，但少数用户等待十秒；系统也可能每秒处理能力不足。
技术怎样介入
Latency 看单次等待，Throughput 看单位时间处理量，Concurrency 看同时进行请求，Percentile 观察尾部体验。
产品与设计怎样落地
性能目标要落到首屏、搜索、锁票和支付等具体节点。
M3 · Chapter 14
性能与规模
理解用户越来越多以后，系统为什么变慢以及如何判断瓶颈。
先看哪些场景
库存与抢购、数据看板、多租户 SaaS、项目与协作、性能与扩容等场景
它是什么
性能描述系统完成任务的速度和容量，规模治理通过缓存、并发、扩容和优化保持体验。
为什么需要
慢可能发生在浏览器、网络、后端、数据库、存储或第三方，优化需要先定位。
位于哪一层
横跨前端、网络、后端、数据和基础设施。
和谁连接
Latency、Throughput、Concurrency、Web Vitals、Query、Cache、Load Balancing、Autoscaling 和 Capacity。
项目里怎么出现
大列表加载、图片首屏、导出高峰、秒杀、AI 流式输出都涉及性能。
Learning Outcomes
学完这一章，你应该能
- 理解延迟、吞吐和并发
- 识别前端、网络、后端和数据库瓶颈
- 理解缓存、负载均衡与自动扩缩
- 建立先测量再优化的判断方式
14.01
Latency、Throughput 与 Concurrency
延迟描述一次有多快，吞吐描述单位时间处理多少，并发描述同时进行多少。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
一个请求 200ms 完成是延迟；系统每秒处理 1000 个请求是吞吐；同时有 500 个请求执行是并发。三者会相互影响。
平均值可能掩盖慢用户，工程常关注 P95、P99 延迟。用户体验还受首屏、交互响应和稳定性影响。
User Load → Concurrency → Resource Usage → Latency / Throughput
System View
Latency：一次耗时
Throughput：单位时间处理量
Concurrency：同时执行量
P95：95% 请求更快
Availability：能否成功访问
Capacity：可承载上限
Designer Lens
“快”要拆成首屏多久、点击多久有反馈、任务多久完成，以及慢用户比例。
LatencyThroughputConcurrencyPercentile
14.02
前端性能
页面速度取决于资源体积、渲染、图片、脚本和主线程工作。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
数据看板CASE 01
一万行表格为什么滚动会卡？
用户正在做什么
运营打开包含大量记录和复杂单元格的列表。
业务会出什么问题
一次渲染全部 DOM 和脚本会占用内存并阻塞交互。
技术怎样介入
Virtual List 只渲染可视行，Lazy Loading 延后资源，Code Splitting 按页面加载代码。
产品与设计怎样落地
设计固定行高、骨架屏、分批加载和滚动位置恢复。
浏览器需要下载 HTML、CSS、JavaScript、图片和字体，再解析和渲染。大型脚本、未优化图片和复杂组件会拖慢首屏与交互。
代码分割、懒加载、图片尺寸、缓存、虚拟列表和减少重渲染可以改善体验。Core Web Vitals 提供页面加载和交互的常用观察维度。
Network Resources → Parse → Execute → Layout → Paint → Interaction
System View
下载资源
→
解析
→
执行脚本
→
布局与绘制
→
可交互
→
后续懒加载
Designer Lens
骨架屏不能替代真实速度；它只改善等待感，仍需降低数据和渲染耗时。
Lazy LoadingCode SplittingVirtual List
14.03
网络与 API 性能
请求数量、数据体积、连接距离和协议都会影响等待。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
多租户 SaaSCASE 01
移动端首页为什么不能一次调用二十个接口？
用户正在做什么
弱网用户打开工作台，需要头像、项目、任务、提醒和统计。
业务会出什么问题
每次 Round Trip 都有延迟，小请求过多也增加 Header 和连接成本。
技术怎样介入
减少 Payload、合并请求或通过 BFF 为移动端聚合首屏数据。
产品与设计怎样落地
定义首屏优先级，次要模块延迟加载，弱网下提供可用的局部内容。
过多串行请求会累积延迟，过大的 JSON 会增加传输和解析，跨地域访问会增加网络往返。压缩、分页、批量接口和并行请求可以改善。
API 应返回页面真正需要的数据，并设置超时和缓存。GraphQL、聚合接口或 Backend for Frontend 可以减少客户端拼接成本。
Request Count × Round Trips + Payload Size + Server Time = User Wait
System View
容易变慢
- 多个串行请求
- 一次返回全部数据
- 跨地域调用
- 无压缩与无缓存
常见改善
- 并行与聚合
- 分页与字段裁剪
- CDN/边缘
- 压缩与缓存
Designer Lens
页面数据依赖图要尽量减少不必要串行，关键内容优先返回。
PayloadRound TripBFF
14.04
后端与数据库性能
业务计算、外部调用和查询是常见服务端瓶颈。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
项目与协作CASE 01
项目列表只有 100 条，为什么却发出 101 次数据库查询？
用户正在做什么
页面展示每个项目及负责人名称。
业务会出什么问题
先查项目，再为每条项目单独查负责人，形成 N+1 Query。
技术怎样介入
通过 JOIN、批量查询或 ORM 预加载减少往返，Connection Pool 复用连接，Profiling 找到热点。
产品与设计怎样落地
列表字段越多，数据查询成本越高；设计时确认首屏真正需要哪些字段。
慢 SQL、缺少索引、N+1 查询、连接池不足和大事务会拖慢接口。CPU 密集计算、同步调用多个外部服务也会累积延迟。
优化需要通过 Profiling、查询计划和指标定位。先解决最大瓶颈，再评估缓存、批处理、异步或数据模型调整。
API Time = Business Compute + Database + External Calls + Queueing
System View
请求排队
业务计算
数据库查询
外部 API
序列化与网络返回
Designer Lens
同一个“加载慢”可能来自列表查询、权限计算、第三方接口或前端渲染，不能只优化动画。
N+1 QueryConnection PoolProfiling
14.05
缓存、负载均衡与自动扩缩
它们分别减少重复工作、分散流量和增加运行容量。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
性能与扩容CASE 01
营销活动突然爆量，系统怎样保持可用？
用户正在做什么
一场直播带来平时百倍流量，大量用户查看相同商品。
业务会出什么问题
单台应用和数据库成为 Bottleneck。
技术怎样介入
缓存热门数据，Load Balancing 分散请求，Autoscaling 根据负载增加实例。
产品与设计怎样落地
高峰期可关闭非核心动画和次要模块，给出库存与排队的稳定反馈。
缓存让高频结果直接返回，负载均衡把请求分给多个实例，Autoscaling 根据指标增加或减少实例。三者解决不同瓶颈。
扩容应用实例无法解决单个慢查询，缓存也无法修复错误数据模型。数据库、队列和第三方服务可能成为新的共享瓶颈。
Cache Hit ↓ Work；Load Balancer → Many Instances；Autoscaler → Capacity
System View
用户流量
→
CDN/缓存
→
负载均衡
→
应用实例扩缩
→
数据库/队列
→
监控反馈
Designer Lens
性能方案要对应真实瓶颈，避免把所有问题都归结为“加服务器”。
Load BalancingAutoscalingBottleneck
14.06
异步、批处理与削峰
不需要立即完成的工作可以移出用户请求，并在稳定节奏中处理。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
消息与通知CASE 01
百万条通知为什么不会同时打爆短信供应商？
用户正在做什么
活动结束后系统需要向大量用户发送结果通知。
业务会出什么问题
瞬时发送会超过供应商和系统吞吐，并放大失败。
技术怎样介入
通过 Queueing 缓冲任务，Batching 合并请求，Backpressure 在下游变慢时限制生产速度。
产品与设计怎样落地
任务中心展示排队和预计完成范围，允许暂停、取消和失败重试。
批量导入、图片处理、邮件发送和 AI 生成可以放入队列。高峰请求先进入队列，Worker 按可承载速度消费。
批处理把多个小操作合并，减少网络和数据库开销。用户需要看到排队、进度、预计时间和失败记录。
Traffic Spike → Queue Buffer → Controlled Workers → Result
System View
高峰请求
→
快速接受
→
队列削峰
→
并行 Worker
→
批量写入
→
完成通知
Designer Lens
性能优化会改变体验形态：即时完成可能变成任务中心和后台通知。
BatchingBackpressureQueueing
14.07
先测量，再优化
性能优化需要基线、目标、定位和验证。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
数据看板CASE 01
页面慢时，为什么不能凭感觉先加缓存？
用户正在做什么
团队认为看板慢是数据库问题，实际可能是前端渲染或网络传输。
业务会出什么问题
没有数据就优化，可能增加复杂度却没有效果。
技术怎样介入
先用 Benchmark 建基线，再用 Load Test 模拟流量，通过 Capacity Planning 判断资源和瓶颈。
产品与设计怎样落地
在体验指标中记录真实用户等待和关键任务完成时间。
先定义用户任务和指标，收集真实数据，找到主瓶颈，再进行最小有效修改。优化后要比较前后结果并观察副作用。
过早优化会增加复杂度。性能、成本、开发速度和一致性之间存在取舍，目标应与业务价值和用户影响对齐。
Measure → Find Bottleneck → Change → Compare → Monitor
System View
定义场景
建立基线
定位瓶颈
实施优化
压测/对比
上线观察
持续调整
Designer Lens
把“感觉慢”转成可测问题：哪个页面、哪个动作、哪个分位、哪类用户、目标是多少。
BenchmarkLoad TestCapacity Planning
Chapter Recap
本章小结
- 01延迟、吞吐、并发和容量描述不同性能维度。
- 02瓶颈可能位于浏览器、网络、后端、数据库或外部服务。
- 03缓存、负载均衡、扩缩、队列和批处理解决不同问题。
- 04性能优化遵循测量、定位、修改和验证。
Practice
把认知变成一张图
选择一个你觉得慢的页面，列出浏览器、网络、API、数据库四层各两个可能瓶颈和对应指标。
Quick Check
随堂检查
QUESTION 01
每秒处理请求数量属于哪个指标？
吞吐量描述单位时间完成多少工作。
QUESTION 02
给应用增加实例一定能解决慢 SQL 吗？
扩容应用层无法自动修复数据库层瓶颈。