等待的艺术：一个关于网站速度的心理学实验

> **导读**：这是一篇关于"等待"的技术故事。当用户点击一个链接，等待页面加载的那一瞬间，发生了什么？从1.17秒到100毫秒，我们经历的不仅是一次技术优化，更是一场关于"时间感知"的深刻探索。 --- ## 🎭 序章：那个让人抓狂的等待 想象一下这个场景： 你走进一家咖啡店，点了一杯拿铁。咖啡师接过你的订单，然后——消失了。一分钟后，他才慢悠悠地开始磨咖啡豆。这一分钟里，你站在柜台前，盯着空白的墙面，感觉像过了一辈子。 这就是我们的网站用户曾经面临的困境。 我们的论坛 homepage，首次字节时间（TTFB）高达 **1.17 秒**。这意味着用户点击链接后，要等待超过一秒，浏览器才开始收到任何数据。在心理学上，人类的感知阈值大约是 100 毫秒——超过这个时间，"即时响应"的感觉就消失了。1.17 秒？那已经是"明显卡顿"的范畴。 > **注解**：**TTFB**（Time To First Byte，首次字节时间）是从用户发起请求到浏览器收到第一个字节数据的时间间隔。它不包含页面渲染时间，只衡量"服务器反应速度"。这就像一个服务员从接到订单到端上第一道菜的速度——不管菜做得多精致，如果让顾客干等一分钟，体验就已经打了折扣。 但最奇怪的是：我们的服务器配置并不差——2 核 CPU、4GB 内存，运行着当时最新的 FrankenPHP 1.12。为什么一个简单的首页查询会慢成这样？ 这个问题困扰了我很久，直到有一天，我开始像费曼那样思考：**如果我是一个请求，我会经历什么？** --- ## 🔬 第一章：走进请求的内心世界 让我们做一个小实验。想象你是一个 HTTP 请求，刚刚从用户的浏览器出发，目的地是 `zhichai.net`。 你风驰电掣地穿过互联网的高速公路，DNS 查询、TCP 握手、TLS 加密——一切顺利。然后，你到达了服务器的大门前。 你敲门。 门开了，一个 PHP-FPM 进程睡眼惺忪地看着你："什么事？" "我要访问首页。" "哦，稍等。" PHP-FPM 进程打了个哈欠，"我得先加载整个 PHP 解释器、所有框架文件、初始化数据库连接..." 你站在那里等。一秒、两秒... 终于，一切准备就绪，PHP 开始执行业务逻辑。但就在这时——它发现需要查询数据库。于是它拨通了数据库的电话： "喂，数据库吗？我需要首页的话题列表。" 数据库回复："好的，给你。" PHP 拿到列表，一看：有 20 个话题。它需要为每个话题查询作者信息。于是它又拨通电话： "喂，第一个作者的信息？" "第二个呢？" "第三个..." 这就是臭名昭著的 **N+1 查询问题**：1 次列表查询 + N 次详情查询。如果列表有 20 条，就是 21 次数据库往返。 最后，PHP 终于把所有数据拼凑成 HTML，交给你："好了，带回去吧。" 你回头一看，已经过去了 1.17 秒。 --- ## 🧩 第二章：Worker Mode——那些不睡觉的服务员 了解了问题的本质，解决方案就呼之欲出了。 想象一家繁忙的餐厅。如果每个顾客来了，服务员都要从零开始穿衣服、系围裙、熟悉菜单，那服务速度肯定慢得令人发指。聪明的餐厅会怎么做？让服务员提前准备好，穿着整齐站在岗位上，随时待命。 这就是 **FrankenPHP Worker Mode** 的核心思想。 传统的 PHP-FPM 是"无状态"的——每个请求来了，启动一个新的 PHP 进程，请求结束，进程销毁。这就像每次服务完一个顾客，服务员就回家，下个顾客来了再重新招聘、培训、上岗。 Worker Mode 则完全不同。它预先生成一组 PHP 进程（称为 Workers），这些进程在服务器启动时就完成了框架加载、数据库连接池初始化等所有"准备工作"。当请求到来时，它们直接接过任务，省去了一切初始化开销。 > **注解**：**Worker Mode** 是 FrankenPHP 提供的一种运行模式，借鉴了 Go 语言和 Swoole 等异步框架的理念。传统 PHP 的"共享nothing"架构虽然带来了良好的隔离性，但每次请求都重新初始化的开销在高并发场景下成为瓶颈。Worker Mode 通过保持进程常驻内存，实现了类似 Java 或 Node.js 的持续服务能力。 但这里有一个关键的认知误区——这也是我踩过的坑。 我最初以为 Worker 配置应该放在站点级别： ```caddy zhichai.net { php_server { worker /path/to/worker.php 8 # 这是错误的！ } } ``` 反复调试，发现 Worker 根本没有生效。直到我仔细研究了 FrankenPHP 的架构，才恍然大悟： **Worker 必须在全局 `frankenphp` 代码块中配置！** 正确的配置是： ```caddy { frankenphp { worker /var/www/zhichai.net/public/frankenphp_worker.php 8 } } ``` 为什么？因为 Workers 是全局资源，它们在服务器启动时就被创建，服务于所有站点。把 Worker 配置放在站点级别，就像是试图让每个餐厅包间都有自己的招聘部门——架构上就错了。 当 Worker Mode 正确启用后，TTFB 从 1.17 秒骤降至约 **300 毫秒**——仅仅是消除重复初始化的成果。 --- ## 💾 第三章：记忆的艺术——APCu 缓存的奥秘 300 毫秒已经很不错了，但还能更好。 让我们回到餐厅比喻。服务员现在随时待命了，但每次顾客点"今日特价"，服务员都要跑去厨房问厨师今天特价是什么——即使特价一整天都不会变。这显然很愚蠢。 聪明的餐厅会把"今日特价"写在一块小黑板上，放在服务员一眼就能看到的地方。 这就是**缓存**的本质：把昂贵的计算结果保存在廉价的地方。 在我们的场景里，首页的话题列表就是那"今日特价"。它变化不频繁（用户发帖频率远低于访问频率），但计算代价高（涉及 N+1 查询）。 我们选择了 **APCu** 作为第一级缓存。 > **注解**：**APCu**（Alternative PHP Cache User）是 PHP 的一个内存缓存扩展。它把数据存储在进程的共享内存中，读取速度极快（微秒级），因为不需要网络 I/O 或磁盘访问。想象它就像服务员围裙上的便签本——触手可及，比跑去厨房问快得多。 APCu 缓存的代码实现很直观： ```php // 构建缓存键，区分用户角色 $cacheRole = $currentUser && $currentUser->isAdminOrSuperAdmin() ? 'admin' : 'user'; $cacheKey = "homepage:topics:page:{$page}:role:{$cacheRole}"; // 尝试从缓存读取 $topics = $this->apcuService->get($cacheKey); if ($topics === null) { // 缓存未命中，查询数据库 $topics = $this->loadTopicsFromDataSource($page, $pageSize, $includeHidden); // 写入缓存，TTL 60 秒 $this->apcuService->set($cacheKey, $topics, 60); } ``` 这里有一个微妙但重要的设计决策：**角色分离的缓存键**。 普通用户和版主看到的内容是不同的——版主能看到被隐藏的话题。如果我们用同一个缓存键，就会出现"权限泄露"：普通用户可能看到缓存中的隐藏内容，或者版主看不到隐藏内容。 解决方案是在缓存键中嵌入角色信息：`homepage:topics:page:1:role:admin` 和 `homepage:topics:page:1:role:user` 是两个独立的缓存条目。 缓存还有一个重要问题：**过期策略**。 我们设置了 60 秒的 TTL（生存时间），这意味着最多 60 秒，用户就能看到新发布的话题。但对于编辑和删除操作，60 秒的延迟是不可接受的——用户删除自己的帖子后，如果首页还显示它，会让人困惑。 因此，我们需要主动失效缓存。在话题的增删改操作时，清除所有相关的首页缓存： ```php public function clearHomepageCache(): void { // 清除所有角色的首页缓存 foreach (['admin', 'user'] as $role) { for ($page = 1; $page <= 10; $page++) { $this->apcuService->delete("homepage:topics:page:{$page}:role:{$role}"); } } } ``` 引入 APCu 缓存后，首页加载时间进一步降至约 **150 毫秒**——数据库查询从 21 次降到了 0 次（缓存命中时）。 --- ## ⚡ 第四章：JIT——当 PHP 开始学会预判 150 毫秒已经很快了，但我们还有一张王牌没出：**JIT 编译**。 让我们用另一个比喻。想象你是一位厨师，正在做一道复杂的菜。传统的 PHP 就像一个厨师，每次做这道菜都要看着菜谱一步步来：切菜、热锅、下油、翻炒... 每一步都要思考"接下来做什么"。 JIT（Just-In-Time）编译则是这样的：厨师做了几次这道菜后，突然顿悟了——"原来我一直重复同样的动作序列！"于是，这些动作变成了肌肉记忆，不再需要经过大脑的"读取菜谱-理解-执行"过程，而是直接流畅地完成。 > **注解**：**JIT**（Just-In-Time Compilation，即时编译）是 PHP 8.0 引入的重量级特性。传统的 PHP 是解释型语言，每次执行都要经过"解析源代码 → 编译成操作码 → 执行操作码"的过程。JIT 则在运行时把热点代码（频繁执行的代码）直接编译成机器码，跳过了解释器的开销，执行速度可提升数倍甚至数十倍。 FrankenPHP 配合 JIT，就像是给这些"顿悟"的厨师提供了一个永不关闭的厨房——他们一旦形成了肌肉记忆，就永远保持这个状态，随时准备以最高效率工作。 我们的 JIT 配置： ```ini opcache.jit tracing opcache.jit_buffer_size 128M ``` `tracing` 模式是 JIT 的最激进模式，它会分析代码的执行路径，把最常走的"热路径"编译成机器码。128MB 的缓冲区足够容纳我们应用的热点代码。 启用 JIT 后，TTFB 降至约 **100 毫秒**——这是一个心理临界点。100 毫秒以下，用户感知是"即时响应"；100 毫秒以上，开始感觉到"延迟"。 --- ## 🐢 第五章：Redis 的陷阱——快并不总是好的 故事到这里应该结束了——但技术优化从来不会一帆风顺。 在最初的配置中，我设置了 Redis 作为 Session 存储。Redis 很快，对吧？内存数据库，微秒级响应。 但上线后，我注意到一个诡异的现象：**大约有 10% 的请求，TTFB 会突然跳到 1 秒以上**。 这是随机的、不可预测的。我检查了日志，发现了一个线索： ``` Redis connection timeout after 1000ms ``` 真相浮出水面：我们的 Redis 服务器在另一个数据中心。正常情况下，网络延迟只有几毫秒。但网络是不稳定的——偶尔会有丢包、路由抖动、瞬时拥塞。当 PHP 尝试连接 Redis 时，如果网络恰好不给力，它就会阻塞等待，直到超时（我们设置的 1 秒）。 > **注解**：**Session** 是 Web 应用中用于保持用户状态的机制。由于 HTTP 是无状态的，服务器需要一种方式"记住"用户——这就是 Session。默认情况下 PHP 把 Session 保存在文件系统中，但分布式应用常使用 Redis 或 Memcached 来实现 Session 共享。然而，任何网络 I/O 都引入了不可靠性。 这是一个深刻的教训：**快并不总是好的，可靠性同样重要**。 Redis 很快，但它引入了网络依赖。对于 Session 这种关键路径上的组件，网络波动的影响被放大了。 解决方案是回归**文件系统 Session**： ```php // 强制使用文件 Session，避免 Redis 连接超时 $redisSessionEnabled = false; if (isset($sessionConfig['session_save_path'])) { $sessionPath = $sessionConfig['session_save_path']; if (!is_dir($sessionPath)) { @mkdir($sessionPath, 0775, true); } session_save_path($sessionPath); } ``` 文件系统 Session 性能如何？在我们的单服务器架构下，非常好。现代操作系统的文件缓存会把热文件保留在内存中，实际读取速度接近内存访问。更重要的是——它是可靠的，不会因为网络抖动而阻塞。 切换回文件 Session 后，那 10% 的慢请求消失了，TTFB 稳定在 100 毫秒左右。 --- ## 🔗 第六章：符号链接的智慧——因地制宜的解决方案 还有一个有趣的小问题：静态 HTML 文件的访问。 我们的论坛有一个功能，可以把话题导出为静态 HTML 文件，存放在 `/var/www/zhichai.net/htmlpages/` 目录下。这些文件很大（几十 MB），通过 URL `https://zhichai.net/htmlpages/xxx.html` 访问。 但在新的 Caddy 配置下，这些文件返回了 404。 问题的根源在于 Caddy 的 `try_files` 和 `php_server` 的交互。默认配置下，Caddy 会尝试把路径路由给 PHP 处理，而不是作为静态文件服务。 我们有几个选择： 1. **修改 Caddy 配置**，添加复杂的 `route` 规则来特殊处理 `htmlpages` 路径 2. **移动文件**，把它们放到 `public/` 目录下 3. **使用符号链接**（symlink），在 `public/` 下创建一个指向 `htmlpages` 的链接 选项 1 会让配置变得复杂；选项 2 破坏了项目的目录结构约定；选项 3 是最优雅的： ```bash ln -sf /var/www/zhichai.net/htmlpages /var/www/zhichai.net/public/htmlpages ``` 然后简化 Caddy 配置，移除复杂的 `try_files`，让 `file_server` 直接处理静态文件： ```caddy zhichai.net { root * /var/www/zhichai.net/public # 静态文件缓存 @static { path *.html *.htm ... } header @static Cache-Control "public, max-age=3600" # PHP Worker 模式 php_server # 静态文件服务（htmlpages 通过 symlink 访问） file_server } ``` 符号链接就像是给文件系统做的一个"快捷方式"——它不改变原始位置，但让文件可以通过另一个路径访问。这种"因地制宜"的解决方案，既保持了代码整洁，又解决了实际问题。 --- ## 🧠 终章：关于优化的哲学思考 回顾这整个优化过程，我学到的不仅仅是技术细节，更是一些关于"性能"的深层思考。 ### 1. 测量先于优化 如果我没有用 `curl -w` 测量 TTFB，我可能还在猜测瓶颈在哪里。现代开发有太多"感觉很快"的错觉——真正的性能只能由数据说话。 ### 2. 层级缓存的策略 我们最终采用了多级缓存架构： - **APCu**（L1）：进程内内存缓存，微秒级，但每个 Worker 进程独立 - **Redis**（L2）：共享内存缓存，毫秒级，跨进程共享 - **数据库**：最终数据源 这就像餐厅的组织结构：围裙便签（APCu）→ 厨房白板（Redis）→ 仓库（数据库）。越快的缓存越靠近服务员，但容量越小、越不共享；越慢的缓存越通用，但访问成本越高。 ### 3. 简单胜过复杂 Redis Session 听起来很"现代化"，但在我们的单服务器架构下，它引入的网络依赖是不必要的复杂性。文件 Session 简单、可靠、足够快。 这让我想起费曼的一个故事：他在计算航天飞机的可靠性时，发现 NASA 的工程师们使用了一个极其复杂的统计模型。费曼问了一个简单的问题："如果每个部件的可靠性是 99%，100 个部件串联后整体可靠性是多少？" 答案是：$0.99^{100} \approx 0.37$——只有 37%。 复杂性是可靠性的敌人。每个额外的组件、每个网络调用、每个外部依赖，都是潜在的故障点。 ### 4. 性能是用户体验 从技术角度看，我们把 TTFB 从 1.17 秒降到了 100 毫秒，提升了 11 倍。但对用户来说，这意味着什么？ 在 1.17 秒时，用户会感觉到"慢"。他们可能会点击刷新，或者以为页面卡住了。在 100 毫秒时，页面"瞬间"出现，用户甚至不会意识到"等待"的存在。 这种差异不是线性的。从 100ms 到 200ms，用户几乎察觉不到；但从 1s 到 2s，体验是灾难性的。性能优化有一个"甜点区"——对于 Web 应用，TTFB 低于 200ms 就进入了这个区域。 --- ## 📚 技术参考 **最终配置摘要：** ```caddy { frankenphp { worker /var/www/zhichai.net/public/frankenphp_worker.php 8 php_ini { opcache.enable 1 opcache.enable_cli 1 opcache.jit tracing opcache.jit_buffer_size 128M opcache.memory_consumption 512 opcache.max_accelerated_files 10000 opcache.validate_timestamps 0 session.serialize_handler igbinary apc.serializer igbinary } } } ``` **优化成果：** - TTFB：1.17s → 100ms（11x 提升） - 数据库查询：21 次 → 0 次（缓存命中时） - Worker 进程：8 个（匹配 2 核 CPU） - 缓存策略：APCu L1 + Redis L2 **关键洞察：** 1. Worker Mode 必须在全局 frankenphp 代码块配置 2. 网络依赖（如 Redis）在关键路径上引入不可靠性 3. 缓存键设计需要考虑权限边界 4. 符号链接是解决路径问题的优雅方案 --- > **写在最后**： > > 优化是一场关于"耐心"的修行。每一次瓶颈的突破，都让我们更深入地理解系统的本质。而最终的目标，不是那些毫秒数字，而是让用户忘记"等待"的存在——就像你呼吸时，不会去思考空气的存在一样。 > > 毕竟，最好的技术，是看不见的技术。 --- *本文作者是一位热爱费曼学习法的全栈开发者，相信"如果你不能用简单的语言解释一件事，那你就还没有真正理解它"。*`