This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.目标：通过一些策略，尽可能缩短 静态 Wordpress网站响应的时间（本笔记不讨论CDN/分布式/动态Wordpress）
除非服务器出现极端的负载爆炸/宕机/无响应，否则任何时候/任何负载下，Wordpress都应该以最快的速度返回任何网页，上述过程可以使用Cache
出发点当然是使用缓存
缓存也有很多讨论的话题，可以有数据库层面的mysql/mariadb query cache，可以有中间层的redis/memcached，可以有基于html的full page cache，可以有适配多种资源类型的varnish，等等。但本文后面的内容都主要讨论html cache.
html cache的一大优化在于“全面的预缓存”，所以一个自己写的preload.py很重要：🔗 [Wordpress cache preload code (python3) - Truxton's blog] https://truxton2blog.com/wordpress-cache-preload-code-example-python3/
一些和本笔记关联不大的笔记也一并列举过来，里面包含了一些我对本站设计的尝试笔记：
🔗 [Memcached和Redis测试（preload.py） - Truxton's blog] https://truxton2blog.com/preload-py-memcached-redis-benchmark/
🔗 [2021-08站点迁移记录 - Truxton's blog] https://truxton2blog.com/2021-08-migrate-my-site/
🔗 [博客设计与部署 修改记录（2021-2023） - Truxton's blog] https://truxton2blog.com/blog-design-and-hosting-record-since-2021-09/
（测试思路有问题，这篇文章现在已经没有太多用处了）🔗 [（娱乐测试）不同Linux发行版的preload.py性能对比 - Truxton's blog] https://truxton2blog.com/2021-11-test-preload-performance-in-different-linux-distributions/
cloudflare cached html应该是最快的，可惜cache miss的比例太高，且普通刷cache脚本（无论是curl还是puppeteer）对cloudflare的算法基本上都没什么用
所以考虑基于服务器的html缓存
wordpress插件缓存要经过php这一层，
而且不同缓存插件的可用性、代码质量、性能、后期维护、费用等都需要花精力比较
wpengine这样的高级wp托管服务商也采用了fastcgi
所以使用fastcgi
fastcgi的缓存文件路径是可以计算的，这里假设preload.py使用了“边删边缓存”策略，影响降到最低
fastcgi的第一步：将fastcgi的文件夹丢到RAM空间，常见的做法是挂载一块tmpfs磁盘，然后把fastcgi文件夹设置在这个tmpfs里面
但是tmpfs也不够稳固，尤其是对于小RAM的vps，稍不留心就有可能被丢到swap file里面去
ramfs当然也不行，风险太大了，系统容易崩 这句话在这篇笔记写完以后终于可以划掉了
新的思路：使用cat这样的命令读取fastcgi缓存文件，从而刷新缓存文件的存储位置（理论上应该有很大概率从swap空间置换到RAM空间），尽可能减少它留在swap file的时间
先把swapiness设置为1
然后开始定期find并cat所有文件
等待后期补充效果
检测是否有效的方法1：
趁服务器不注意，突然ssh进去并运行
$ find /path/to/fastcgi -type f -exec sh -c 'echo Accessing "{}" && cat "{}" > /dev/null' \;如果第1次运行的时候明显卡顿，第2次以后突然就非常流畅了，说明：第1次运行的时候，很有可能，fastcgi还在swap file里面
更新：
这个方案似乎不是很保险，根据chatgpt的说法，要多运行几次才能提高交换到RAM的概率。所以目前的方案暂定为：
每隔一段时间就运行一个程序，把fastcgi文件夹里面的文件都用cat读几遍。
稍等！chatgpt突然给我推荐了个有意思的东西：vmtouch：🔗 [Hoytech] https://hoytech.com/vmtouch/
再补充：还是不太行，因为vmtouch使用了mincore(2)，而根据kernel document，它无法区分RAM和swap . 所以还是回到之前的策略：每隔一段时间就运行一个程序，把fastcgi文件夹里面的文件都用cat读几遍。
方法2：
趁服务器不注意突然curl并分析性能，虽然不能解决问题但至少能“确认问题是真实存在的”：
🔗 [How do I measure request and response times at once using cURL? - Stack Overflow] https://stackoverflow.com/questions/18215389/how-do-i-measure-request-and-response-times-at-once-using-curl
还没成功过，等待后续补充
（黄了）
似乎有了新的转机：
闲着没事我写了篇笔记总结了一下tmpfs和nginx fastcgi参数设置的问题：🔗 [使用tmpfs存储FastCGI缓存文件时要注意的问题 - Truxton's blog] https://truxton2blog.com/set-fastcgi-dir-in-tmpfs-disk/
这篇文章对我启发很大，我突然就想到那个很早之前被我考虑过，但因为 不可控 的原因被舍弃了的ramfs，所以我现在使用nginx conf限制fastcgi缓存文件夹的大小，然后把tmpfs改为ramfs
由于ramfs永远会使用pure RAM空间（而不是swap RAM），所以再也不用担心性能问题了！
还有一个好处就是，ramfs占用的空间是“存多少文件占多少内存”的，而不是像tmpfs那样预先分配的（🔗 [有关ramfs的一些测试 - Truxton's blog] https://truxton2blog.com/some-ramfs-experiments/），所以只需要设置nginx的key_zone/max_size为一个不那么离谱的数值即可。
至少，在目前的服务器架构上我应该是尽力了，（在不大改架构的前提下）暂时想不出什么需要进一步优化的地方了。
