This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.本篇笔记会不定期更新
Table of Contents
调用preload.py重构缓存的次数
调用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/ | 817% |
| https://truxton2blog.com/2023-06-intro-to-linear-optimization-learning-notes-1/ | 510% |
| https://truxton2blog.com/2024-05-learn-pandas/ | 437% |
| https://truxton2blog.com/2022-03-20/ | 288% |
| https://truxton2blog.com/review-java-from-python/ | 204% |
毫不意外，这些笔记都是又臭又长的巨型笔记。好在有很多巨型笔记现在（2024年）都不怎么更新了。
