加载整个 lib/ 实际要花多少
这个服务唯一入口文件的第 46 行： foreach (glob(__DIR__ . '/lib/*.php') as $f) { require_once $f; } 那是 65 个文件、1.5 兆字节，每个请求都要加载一遍。计数器图片、统计页面、404 — 一视同仁。昨天这件事发生了 20,734 次。 26 个样式家族 — 715 KB，用得上一个 旗帜 189 KB…
当缓存朝错误的方向增长
这个服务的缓存目录里有四个小文件。最大的一个 35 字节。它们合起来装着三个计数器编号，而且每一次计数器请求都会读它们。 它们存在，是为了让计数路径不必向数据库提四个几乎总是回答「没有」的问题。这个计数器排除站长自己的访问吗？统计外链点击吗？跟踪站内路径吗？自己重新加载吗？对超过 99 %…
加索引反而更慢的时候
存放每日数字的那张表只有一个键：计数器和日期合在一起。代码里有五处向它提的是另一个问题 — 不是「这个计数器随时间的变化」，而是「这些日子里的所有计数器」。首页的展示区、排行榜、站点地图、一张 90 天的图表，还有状态数字。日期列上没有索引时，它们每一个都要读完全部 114,113 行。 加上那个索引，展示区快十倍。我们没有加。下面是做出这个决定的测量。 展示区，一天 —…
为什么 AI 不跑在我们的服务器上
为本站提供服务的那台机器上，没有跑任何语言模型。摘要是在第二台设备上算出来的，它去取任务、做完计算，再把句子送回来。 理由是算术。一个 3B 模型占用一个多 GB 的内存，每次回答要花几秒。而整个应用里最重的一次数据库查询是 581 毫秒。把两者放在同一块板子上，意味着 379 000 个计数器的图片要排在一个文本生成器后面等——而它们才是真正的产品。 最重的数据库查询581…
把计数器图片放在内存里
本服务绘制的计数器图片里，将近五分之一已经什么都不改变了。上一代留下的鼠标追踪脚本会在每一次移动时重新加载图片，而自从这些请求不再让任何数字增加，连着两次就会产出同一张图片，逐字节相同。 这是缓存的一个明显候选。有意思的是两个决定：把它放在哪里，以及键该基于什么。 不放在磁盘上 这跑在一台小服务器上，而磁盘是一张 SD 卡。把画好的图片缓存到那里，意味着每天大约 70 MB…
2015 年的脚本仍在重载计数器
本服务的上一代带着一个鼠标追踪脚本。它先正常地加载一次计数器图片，之后在每一次鼠标移动时再加载一次——把坐标放进查询串，并带上一个 rerun=1 标志。这名字是诚实的：这是同一次访问的又一遍，不是一次新的。 这些数据从来没有人看过。rerun 这个词在整棵源码树里只出现在一个地方，而那个地方是某个缓存键的排除清单。它从未被分析过。倒是一直在被计数。 它对数字做了什么…
一个密码在低配硬件上要花多少
这里的统计页面可以加密码保护。给这个密码算哈希，是本服务里唯一一个应该慢的操作——正是它让一份被偷走的哈希变得难以攻破。问题只是：在这台硬件上，慢到什么程度。 在运行本站的那台机器上实测，PHP 8： PASSWORD_DEFAULT560 毫秒（解析为 cost 12） cost 12595 毫秒 cost 11277 毫秒 cost 10138 毫秒 cost 10138…
每一次都把同一个文件压一遍
Apache 是即时压缩响应的。对一个每次都不一样的页面来说，这是唯一的办法。对一个一个月才改一次的样式表来说，这意味着服务器为每一位访客把同样的活儿重做一遍，一做几个星期，而且每次都把结果扔掉。这件事没有缓存。 2026 年 8 月 19 日在一条已建立的连接上实测，用的是本站自己的 style.css（124 kB）和 world.js（102 kB）： 时间字节…
不用 JavaScript 的动画计数器
这里相当一部分计数器样式是会动的。数字会自己往上跳动,面板会自己描绘出来,或者有什么东西会落定到位。 它们都不用一行JavaScript。 原理是什么…
Stats4U 3 来了
您现在正在阅读的这个网站,本月经历了一次重建——不是改版,而是从计数路径开始的彻底重建。关于促成这一切的、此前那沉寂的十一年,另有一篇文章专门讲述。这一篇要说的,是究竟改变了什么,以及是哪些测量数据,证明了这件事值得去做。 那个促成决定的数字 在任何工作开始之前,有人统计了究竟有多少计数器图像被正确地送达。答案是,大约只有一半。 在每天大约 4,200 次计数器请求中,有…