WARNING: This article may be obsoleteThis post was published in 2024-02-29. Obviously, expired content is less useful to users if it has already pasted its expiration date.
This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.本篇笔记会不定期更新
Table of Contents
调用preload.py重构缓存的次数
（在2025-09之前）调用preload.py越频繁 = 重构缓存越频繁 = 更新本站内容越频繁 = 在本博客上花了更多时间（不一定是写得多，有的时候就是单纯经常跑上去看看，然后修改点小东西）
重构缓存不频繁 = 可能去忙别的了
（在2025-09之后）引入了新的【reload-最近10篇】策略，大幅度降低了对全站preload的需求，所以preload.py执行频率以后会显著降低。
Nginx fastcgi缓存html文件数
也就是本站全部页面数。
第1个断层的原因：本站决定删除之前的一堆乱七八糟的Tags，使用了新的tag体系
Nginx fastcgi 缓存文件大小（总和）
和上面的 本站全部页面数 相似，但波动幅度较大（因为经常修改本站html结构）
第1个断层（2022年12月前后）的原因：本站决定删除之前的一堆乱七八糟的Tags，使用了新的tag体系
后面几个断层的原因：引入了左侧菜单栏的文章聚合导航，页面大小波动幅度大
平均页面生成时间
一定程度上反映了本站部署的环境配置与服务器性能
参考🔗 [评价本站用过的VPS服务商（2023年6月更新） - Truxton's blog] https://truxton2blog.com/review-my-used-vps-providers/ 上面这张图的注释版本如下：
双核preload由于吃满了hetzner的双核cpu，所以平均每个页面的生成时间都要比单核preload多差不多一倍。后来我想通了，preload只要能在合理的时间内跑完就行，占满cpu资源反而会带来其他弊端。所以本质上目前这个【能够跑多线程】的preload.py是用单线程跑的。也许以后用上4核甚至更多核的cpu就能开一半的核心跑preload.py了。
生成速度最慢的几个页面
有些笔记实在是太长了，生成这些笔记的html页面当然会花费最多的时间
这里假设一次preload跑完以后，所有页面的平均生成时间为100%
（为了防止远古时期的数据平均起来干扰现在的结果，所以只取最近50次preload的结果进行统计）
| url | 相对平均页面生成时间（当次preload执行完毕后所有页面的平均生成时间为100%） |
| https://truxton2blog.com/macbook-play-asphalt8-record/ | 535% |
| https://truxton2blog.com/2024-05-learn-pandas/ | 425% |
| https://truxton2blog.com/2023-06-intro-to-linear-optimization-learning-notes-1/ | 375% |
| https://truxton2blog.com/2022-03-20/ | 217% |
| https://truxton2blog.com/blog-design-and-hosting-record-since-2021-09/ | 179% |
毫不意外，这些笔记都是又臭又长的巨型笔记。好在有很多巨型笔记现在（2025年）都不怎么更新了。
WordPress写作时间
上面的统计都是基于preload.py活动记录的，但有的时候会出现：
- 在调试新的preload.py脚本/新的机器，频繁调用preload.py
- 专心写草稿，没有公开发表新的文章，也没怎么调用preload.py
所以新增了一个Wordpress写作频率统计（由于代码原因，2022-07之前的没有统计）。
下面的统计基于Wordpress autosave rest API的调用频率：🔗 [Wordpress Autosave Rest API Hook - Truxton's blog] https://truxton2blog.com/wordpress-autosave-rest-api-hook/
