slow → fast computers

### TL;DR 性能工程师需要深刻理解延迟、吞吐量、资源利用率等指标，并熟悉常见操作的延迟数字（如 CPU 指令、磁盘读取、网络访问），因为直觉上的“快”与“慢”往往与现实相差几个数量级。 --- ## 《系统性能》第二章：核心概念概述 在直播中我们继续阅读《系统性能》这本书（约 800 页，内容密集却精彩）。第二章是对全书的宏观预览，涵盖了性能调查中涉及的所有关键指标：延迟、吞吐量、IOPS、资源利用率、饱和度，以及缓存层级如何影响性能。本章为后续章节的深度讨论奠定了基础。 ## 性能指标：延迟 vs 吞吐量 vs 资源利用率 vs 饱和度 当你测量系统性能时，需要选对指标。核心问题包括： - **延迟**：单个操作花费的时间（如请求响应时间）。 - **吞吐量**：单位时间内完成的操作数（如每秒请求数）。 - **IOPS**：输入/输出操作每秒的次数（常用于存储系统）。 - **资源利用率**：某资源（CPU、内存、磁盘）被使用的百分比。 - **饱和度**：资源无法及时满足请求的程度（往往导致队列堆积）。 书中强调，这些指标需要组合使用，仅看一个指标可能误导。例如，高利用率不一定是问题，但若同时伴随高饱和度，则表明需要扩容。 ## 缓存层级：CPU 缓存、RAM、磁盘 性能优化的核心思想之一是“缓存无处不在”。书中总结的缓存层级包括： - **CPU 缓存（L1/L2/L3）**：对物理 RAM 的缓存。 - **RAM**：对磁盘（SSD/HDD）的缓存。 - **磁盘中的缓存**：如 SSD 内部的 DRAM 缓存。 - **网络缓存**：CDN、DNS 缓存等。 理解这些层级之间的延迟差异至关重要。书中引用了一个经典表格（在业内常被称为“每个工程师应该知道的延迟数字”），其中列出了从 CPU 指令到网络跨区传输的典型时间。例如： - L1 缓存引用：约 0.5 ns - 分支预测错误：约 5 ns - L2 缓存引用：约 7 ns - 主存引用：约 100 ns - SSD 随机读取：约 150,000 ns - 跨美国网络往返：约 150,000,000 ns 这些数字的差距可达几个数量级，记住它们能让你快速识别性能瓶颈。 > 可视化这些数字（如用不同大小的球体表示）是一种有效的记忆方法。虽然看起来有点傻，但它能帮你在大脑中建立直观的延迟规模概念。 ## 延迟数字资源：Jeff Dean 与 Simon Eskilden 除了书中的表格，还有两个著名的资源： - **Jeff Dean**（Google 研究员）的经典文章《每个工程师应该知道的延迟数字》。 - **Simon Eskilden**（TurboPuffer）的“餐巾纸数学”仓库，其中包含基于实际基准测试的数字，而非仅近似值。 这些资源对任何工程师都极其有价值，尤其是从事数据库、分布式系统或后端工程的人。当你知道常见操作的预期性能后，一旦实际表现偏离，你就能立即察觉并着手调查。 ## 学习建议：动手实践是王道 对于“想入门系统设计/性能工程”的提问，最核心的建议是：**没有东西可以替代动手实践**。加入处理真实挑战的团队、从有经验的人那里学习，是成长最快的方式。书籍和论文是极好的辅助工具，但不能只靠阅读。例如： - 《数据密集型应用系统设计》（DDIA） - 《数据库内部原理》 - 以及本系列正在阅读的《系统性能》 这些资源可以作为你在工作中遇到问题时的参考，帮你将理论与现实结合。 ## 高频交易：性能敏感度的极致体现 当讨论到低延迟性能时，书中提到高频交易（HFT）是世界上最注重性能的领域之一。交易完成的每一毫秒都可能影响盈利或亏损。因此，HFT 对数据库、网络、CPU 调度等所有层级的延迟都有近乎苛刻的要求。无论是否从事该行业，了解 HFT 的极端优化思路都有助于理解性能工程的极限。 ## 直播系列与资源 本系列直播会保留录像并上传至 YouTube 播放列表，方便回看。如果喜欢这类内容，请订阅并打开通知。下一场直播将继续第二章的剩余部分，欢迎随时加入讨论。 --- **Source**: [YouTube Video: slow → fast computers](https://www.youtube.com/watch?v=5Zb8WwKd-E8)