标签: #performance

한국어English日本語中文

← 全部文章

• 300 倍不是调 PostgreSQL 调出来的数字 —— 火山模型与向量化执行

  精确解剖随 pgrust 0.2 发布一起公开的那个 300 倍。这个数字不是改 PostgreSQL 配置得来的，而是把一个用 Rust 重写的数据库放到 ClickBench 上测出来的结果；而作者另外给出的 SUM 查询实验，是从火山模型的 1.3 秒到 SIMD 的 135 毫秒，也就是 9.6 倍。我们在代码层面跟一遍批处理、算子融合、SIMD 各自消掉了什么，并把作者自己讲明的局限，和你今天就能在真实 PostgreSQL

  2026-08-09 · 12 分钟阅读 #postgresql#database#performance#query-engine#simd

• 一条指令可能要跑 62 秒 —— 延迟是路径的属性，不是指令的属性

  Assembly Hall of Shame 是一份「把单条指令跑到最慢」的比赛排行榜。垫底的 nop 是 1 个周期，第一名 fxrstor64 是 1,980 亿个周期，也就是 62 秒。把这份榜单从下往上读，它就成了现代 CPU 所有可能停顿之处的清单，并分成三个区段：微码辅助路径、跨缓存行的原子操作、TLB 失效、熵池枯竭，以及片外的 PCIe 总线。这张表真正证明的是，指令延迟这个概念离开周边状态就无法定义，而由此可以得出关于

  2026-08-09 · 15 分钟阅读 #os-concepts#performance#cpu#microarchitecture#benchmark

• 亲手改一个 GPU kernel 到底意味着什么 —— 把一个转置 kernel 提速 5 倍

  从线程、warp、内存层级讲起，梳理亲手修改 GPU kernel 到底意味着什么。从 roofline 的视角解释为什么占用率是症状而不是目标，以及为什么大多数 kernel 受限于内存带宽而不是计算。把一个矩阵转置 kernel 从 naive 一路改到合并访问、共享内存分块、消除存储体冲突这四个阶段，并提供了在每个阶段实测有效带宽的基准测试工具。最后梳理了在 Nsight Compute 里具体该打开哪些 section、该看什么

  2026-08-02 · 26 分钟阅读 #cuda#gpu-kernel#nsight-compute#memory-bandwidth#performance

• 平均值什么也说明不了——如何用分布调试延迟

  2026 年 7 月 27 日发布、登上 Hacker News 榜首的 Farid Zakaria 文章《The mean means nothing》，讨论了这样一种情形：部署缓存层之后，平均延迟从 112ms 恶化到 122ms，上升了 9%。而在同一份数据中，p50 从 99ms 改善到 54ms，下降了 46%；p99 则从 309ms 恶化到 678ms，上升了 119%。同一份数据之所以能同时支持两个截然相反的结论，是因为

  2026-07-31 · 22 分钟阅读 #observability#latency#performance#histogram#percentile

• Java Value Objects(JEP 401)带来的改变 —— 放弃身份标识,得到什么、失去什么

  2026 年 7 月 31 日 00:45 UTC,JEP 401 Value Objects 的实现被合并进了 OpenJDK 主线。它与 JEP 539(Strict Field Initialization)打包在同一个提交里,涉及 1,888 个文件、新增约 20.8 万行代码 —— 距离 Project Valhalla 于 2014 年启动,已经过去了 12 年。本文依据 JEP 原文,梳理没有身份标识的对象究竟是什么、性能

  2026-07-31 · 22 分钟阅读 #java#jvm#valhalla#jep-401#performance

• 分布式追踪真正回答的问题 — 跨度、采样，以及时间到底花在哪里

  当「慢」的反馈不断进来、却不知道十个服务里谁是凶手时，你需要的就是追踪。本文从追踪、跨度与上下文传播的结构讲起，梳理出日志和指标在原理上回答不了的问题是什么。文中结合采集器配置，讲清自动埋点覆盖到哪里、哪些位置必须补上手动跨度、头部采样为什么会优先丢掉你最需要的追踪，以及尾部采样如何解决这一点、代价又是什么。接着讲跨消息队列传播上下文时为什么要用链接而不是父子关系，最后给出在真实追踪界面上到底该找什么的排查顺序。

  2026-07-26 · 21 分钟阅读 #observability#distributed-tracing#opentelemetry#tail-sampling#performance

• HTTP Keep-Alive 与连接复用 — 制造间歇性 502 的超时竞态条件

  后端日志里一个错误都没有，却唯独负载均衡器上间歇性地混进 502，这多半是连接复用的竞态条件。就在服务器关闭空闲连接的那一瞬间，客户端往这条连接上写入请求，于是 FIN 与请求擦肩而过。本文整理了为什么后端 keepalive 超时要设得比负载均衡器空闲超时更长、如何用 curl -w 把 namelookup 与 connect 与 appconnect 与 starttransfer 拆开以定位瓶颈、如何用利特尔法则确定连接池大小，

  2026-07-26 · 20 分钟阅读 #network#http#performance#load-balancer#tcp

• 为什么平均负载不是 CPU 使用率 — load average 24 而 CPU 只有 30% 的时候

  本文讨论这样一种情况：uptime 的 load average 已经超过 24，而 top 里的 CPU 却连 30% 都不到。Linux 的平均负载与其他 Unix 不同，它不仅统计处于运行等待 (R) 的任务，还把 D 状态 (uninterruptible sleep) 的任务一并计入，因此仅仅是磁盘或 NFS 等待就足以让这个数字飙升。文章梳理三个数字如何由 5 秒采样与指数移动平均生成、按核心数相除的习惯在哪里失效、负载高但

  2026-07-26 · 17 分钟阅读 #linux#performance#load-average#psi#troubleshooting

• git 变慢的时候 — 让大型仓库重新变快的结构性处方

  仓库变慢的原因不止一个。提交历史太长、文件数量太多、里面塞了大的二进制文件，这是三个不同的问题，处方也各不相同。本文先从区分原因的测量命令讲起，说明浅克隆和部分克隆为什么不是彼此的替代品而是用途不同的工具，sparse-checkout 和文件监视如何把 status 缩短，以及 commit-graph 为什么能把日志和合并基准点的计算改变得那么明显。文中还讲了"用 aggressive 跑 gc"这条常见建议为什么大多是亏的，为什么

  2026-07-26 · 16 分钟阅读 #git#performance#monorepo#git-lfs#version-control

• 连接池开太大反而吃亏的原因 — 把队列排在哪里

  本文梳理把连接池调大反而变慢这一现象背后的原理。在 PostgreSQL 的进程模型下连接为什么昂贵,既然磁盘与 CPU 的并行度有限,为什么把队列排在连接池而不是数据库内部更划算,以及常被引用的核数公式的依据与局限。文章还会结合真实查询讲解微服务中实例数乘以池大小超过最大连接数的典型事故、PgBouncer 的三种模式与事务模式下无法使用的功能、如何用 idle in transaction 抓连接泄漏,以及无服务器环境的特殊性。

  2026-07-26 · 21 分钟阅读 #database#postgresql#connection-pool#pgbouncer#performance

• EXPLAIN ANALYZE 阅读法 — 从执行计划中找出真正瓶颈的顺序

  本文梳理如何从头到尾读懂 EXPLAIN ANALYZE 的输出。应该按什么顺序读节点,cost 为什么不是时间单位,预估行数与实际行数之间的偏差说明了什么,loops 会被相乘的陷阱又该如何避开,全部结合真实输出来讲解。同时涵盖 Nested Loop、Hash Join、Merge Join 各自被选中的条件,以及如何用 BUFFERS 判断缓存命中。文章还会给出依据,说明 Seq Scan 并不总是坏事。

  2026-07-26 · 17 分钟阅读 #database#postgresql#explain#query-optimization#performance

• 真正把 Core Web Vitals 修好 — 用数字压下 LCP、INP、CLS 的顺序

  Lighthouse 拿了 98 分，Search Console 却一直亮红灯，原因是这两个工具测的根本不是同一件事。本文先梳理 LCP、INP、CLS 各自测量什么，以及阈值为什么以 75 百分位为准。接着以可落地的程度讲清：如何把 LCP 拆成 TTFB、资源发现延迟、加载时长、渲染延迟四段来决定该修哪里，INP 取代 FID 的原因以及真正让出长任务的代码，还有 CLS 的三大元凶与各自准确的解法。最后延伸到把性能预算挂在单项指

  2026-07-26 · 20 分钟阅读 #performance#core-web-vitals#lcp#inp#cls

• 把 HTTP 缓存用对 — Cache-Control、ETag 与 stale-while-revalidate 的准确含义

  no-cache 的意思不是「不要缓存」，而是「可以缓存，但用之前必须验证」。本文从这一字之差出发，梳理 Cache-Control 各指令的准确含义、条件请求与 304 真正省下的东西和省不下的东西，以及带哈希的文件名加 immutable 为什么成了前端发布的标准组合。还会谈到浏览器、CDN、反向代理这三层各自只能用不同方式失效这一事实，Vary 头把缓存键炸开的过程，以及 stale-while-revalidate 同时兼顾延迟

  2026-07-26 · 16 分钟阅读 #web#http-caching#cache-control#cdn#performance

• 为什么偏偏在关键时刻崩盘 — 窒息效应的心理学与抗压训练法

  练习时完美无缺，上场却一败涂地——这种现象叫作窒息效应（choking），它不是天赋或努力的问题，而是注意系统的失灵。本文从1993年温布尔登决赛的亚娜·诺沃特娜说起，剖析窒息效应的真面目，讲清显性监控理论与注意分散理论这两种机制，并把运动心理学反复验证过的解药——压力接种训练、外部焦点、过程目标——应用到开发者的现场演示、编程面试和故障处理场景中。

  2026-07-20 · 10 分钟阅读 #mindset#sports-psychology#pressure#performance#confidence

• Content-Encoding: zstd — Safari 26.3 补齐三大引擎，下一步是 RFC 9842 压缩字典

  2026年2月，Safari 26.3 支持了 Content-Encoding: zstd，继 Chrome 123(2024-03)、Firefox 126(2024-05) 之后，三大浏览器引擎现在都能接收 zstd 响应了。由于是基于协商的，采用风险很低，但服务器端仍然不对称 — nginx 和 Apache httpd 都没有官方 zstd 模块，现实可行的路径是 CDN(如 Cloudflare)、Caddy，或者 Node

  2026-07-17 · 17 分钟阅读 #performance#web#network#browser

• ClickHouse 的 Lazy Materialization — LIMIT 10 的小技巧是如何长成 FINAL 和 JOIN 的

  ClickHouse 的 lazy materialization 是一种在排序和 LIMIT 完成之前不读取 SELECT 列的优化，它在 25.4(2025 年 4 月)以「仅在 LIMIT 10 及以下时才生效」的保守姿态首次登场。此后，在把逐行 lookup 改造成 join 式批量获取的 25.12 中，这道闸门被提高到 10,000；进入 2026 年后，同一个思路又扩展到 26.2 的 UNION ALL 全部分支、26.

  2026-07-17 · 22 分钟阅读 #database#clickhouse#olap#query-optimization#performance

• Triton Gluon — 把编译器藏起来的布局，重新用手写出来的语言

  Gluon 是搭建在 Triton 同一套编译器栈之上的底层 GPU 语言，它把 Triton 一直藏起来的布局、共享内存、warp 特化，原样交还给写内核的人。它存在的理由很明确 — 当 Triton 编译器生成的代码不够好时，过去你根本没有办法插手。本文会追踪 Gluon 到底暴露了什么、BlockedLayout 具体意味着什么，以及上游教程在 GB200 上记录的测量值(同一个 memcpy，仅凭一个布局，就能在 0.774 T

  2026-07-16 · 28 分钟阅读 #gpu#triton#kernel#compiler#performance

• 为什么 QUIC 在快速互联网上反而更慢 — 接收端 CPU 与尚未到来的内核 QUIC

  QUIC 在握手延迟和丢包恢复上确实赢了。Google 在互联网规模上测得的搜索延迟下降 8.0%(桌面端)、视频卡顿率下降 18.0%，就是证据。可一旦链路变快，情况就会反转 — WWW 2024 的一项测量研究报告称，带宽达到 1 Gbps 时，Chrome 中的 QUIC 会比 HTTP/2 慢 45.2%，而真凶既不是常被指责的加密，也不是服务器，而是接收端客户端的数据包处理成本。本文分别用一手测量资料确认 QUIC 赢在哪里、

  2026-07-16 · 30 分钟阅读 #network#protocol#performance#linux-kernel

• React Compiler 移植到了 Rust — 已合并的、尚未合并的，以及那个"10 倍"的数字

  2026年6月9日，将 React Compiler 移植到 Rust 的 PR 36173 合并进了 facebook/react 的 main 分支。461 个文件、超过 12 万行代码被加入，"作为 Babel 插件快 3 倍，转换逻辑本身快约 10 倍"这个数字很快就开始在生态圈里流传。但在 PR 正文里，作者 Joseph Savona 本人明确写道——"性能数字是 AI 得出的，我没怎么花时间去验证基准测试的设置"。本文只依

  2026-07-16 · 28 分钟阅读 #react#rust#compiler#performance#frontend

• Redis 8.8 的 Array 类型 — 自 Stream 之后首次新增的核心数据结构，以及 Valkey 没有的东西

  2026 年 5 月，Redis 8.8 与 Valkey 9.1 相隔六天先后发布。Redis 8.8 加入了 antirez 亲自打造的全新核心数据结构 Array — 一种面向「索引本身就带有意义」的数据(传感器的分钟级槽位、预订系统的座位号、文件的行号)的稀疏索引容器，配备 18 个命令、基于切片的稀疏编码、服务端聚合，乃至正则 grep。从 server.h 里的对象类型编号来看，这是自 Stream(5.0)之后首次新增的核

  2026-07-16 · 23 分钟阅读 #redis#valkey#data-structures#performance#open-source