WARNING: This article may be obsoleteThis post was published in 2021-11-28. 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
2021
从2021-08的网站迁移结束后开始记录：
把mariaDB的连接方式设置为unix socket：
$ lsof -U | grep mysql然后修改配置文件
// wp-config.php
define( 'DB_HOST', 'localhost:/path/to/mysql.sock' );对速度的提升可能肉眼看不出来，但无论如何，从理论上来看这都是稳赚不赔的设置。
似乎和MySQLTuner-perl给出的建议不同，MariaDB建议用户加大对 table_open_cache 的资源投入（见：https://mariadb.com/kb/en/optimizing-table_open_cache/）。按照MariaDB的建议，我把 table_open_cache 设定为2000，观察一段时间后发现这个数值设定的还不错。所以目前我的设置仍然为： table_open_cache=2000 .
效仿NGINX FastCGI，我把Autoptimize的缓存目录（默认为/wp-content/cache/Autoptimize）也挂载为tmpfs RamDisk了。
$ sudo mount -t tmpfs -o size=100M tmpfs /path/wp-content/cache后续更新：由于新服务器内存吃紧+Autoptimize缓存目录占用空间不可控，决定还是回归普通的磁盘存放文件。
由于使用了CloudFlare作为CDN，现在需要使用NGINX Module ngx_http_realip_module获取真实IP（否则只能获取到CloudFlare节点的IP）：
首先要确定NGINX安装了ngx_http_realip_module模块：
$ nginx -V 2>&1 | tr ' ' '\n' | grep --color realip然后添加这段配置文件（添加在http{...}里面）：
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2c0f:f248::/32;
set_real_ip_from 2a06:98c0::/29;
#use any of the following two
real_ip_header CF-Connecting-IP;
#real_ip_header X-Forwarded-For;参考：https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs
尝试从MathJax 2.7.9换到Katex 。得益于我显著区分了4个delimiters，仅仅对.sql使用简单的 sed 命令就完成了全站切换。Katex总的来说还算满意，能兼容MathJax 2的 \\ 换行写法，但我最后还是换回了MathJax——我喜欢SVG。
LightBox插件的更换：我曾经抱怨过WP官方插件市场没有100%让我满意的LightBox插件。之前我一直在用Lightbox with PhotoSwipe，但现在突然找到了更好的选择：
ARI Fancy Lightbox – WordPress Popup
太好了！
后续更新：我还是用自己写的代码换下了这个插件，使用fancybox 3.5.7，具体原因见：2021-12-12
尝试从MathJax 2.7.9换到MathJax 3.2.0 . 只需要修改一些配置文件就可以迁移了，但是——非常遗憾，MathJax 3至今都没有搞定 \\ 作为line breaking的功能，见：https://github.com/mathjax/MathJax/issues/2312 . 所以我又回退到了2.7.9 。
我发现我一直在使用的codemirror插件体验很差（主要体现在横向滑动条上：横向滑动条会乱动），只能把warp long lines设置为yes .
如果codemirror的问题一直没有解决，我就需要继续寻找能够全屏、能够复制代码、最好使用（prismjs或highlight.js或codemirror）渲染库的插件。目前只找到一个比较满意的，但可惜它和theme绑定了：https://github.com/mashirozx/sakura
自从发现了https://github.com/mashirozx/sakura有关全屏显示的代码也“不算太难模仿”以后，我越来越无法忍受codemirror糟糕的设计了，终于我还是花了一大堆时间进行了一次整站迁移，包括修改Prisma的代码以及迁移所有的文章内容。
出于合并http请求、合并JS文件的强迫症（虽然这些东西在HTTP/2时代已经没有用了），我还是从MathJax 2.7.9换到了MathJax 3.2.0 ，花了一些时间迁移MathJax的换行符，把所有 \\ 改为 \displaylines{} 或 \begin{gathered}...\end{gathered} ，见：
在MathJax 3里，原本需要逐个http请求的一大堆JS文件现在合并成了一个tex-svg.js（1.6M）.
添加了对SVG的支持，使用插件：https://wordpress.org/plugins/svg-support/
尝试使用nginx配置： gzip_static on; ，但一直没有想出很好的后续方案（因为Cloudflare的自动gzip和brotli，以及自动缓存js, css文件），所以思考到最后我干脆把nginx gzip关了：
gzip off;这样可以进一步降低cpu负荷：反正无论我怎么改，Cloudflare都会给我的结果蒙上一层gzip/br压缩传输。不如不压缩，全部丢给Cloudflare来处理。
花了很多时间（又一次）去搞Critical CSS：这一次因为有root权限，打算直接在服务器上跑nodejs critical，但搞了很久最终还是放弃了：
1，Nodejs critical真的很慢，如果要对每个页面都跑critical那恐怕到了下一次purge and preload的时候都未必能跑完...
2，FastCGI生成的缓存html文件并不是100% html：文件的开头有一段FastCGI自己标示的数据块。所以critical CSS生成的html是没办法直接替代FastCGI的 .
出于好奇心，再次尝试了一次Redis/Memcached相关的东西，效果依旧：尽管查询次数降了大概2/3，但preload的总体时间并没有降低（反而升高了一些）。
关于url trailing slash，见：https://searchfacts.com/url-trailing-slash/
尽管Google一视同仁地对待两种url写法，但作为个人，总是想跟着大公司/集体潮流/大众用户偏好...来设置。
因为 Yoast, RankMath, ahrefs 等SEO网站也都使用了trailing slash风格，所以本站将保持原有trailing slash习惯不变。
关于Mysql/Mariadb query_cache
很多（年代久远的）Wordpress优化相关的中文博客会建议开启 query_cache_size ；
但是，我似乎看到近几年很多stackexchnage社区问答建议不开启 query_cache_size ，所以我也一直设置 query_cache_size=0 。今天偶然又想到了这个问题并且去尝试了一下，发现开启 query_cache_size 能缩短整站preload的时间，这可能和本站的缓存习惯有关（局部修改、全体清除、集中资源一次性preload所有缓存：就像hexo/hugo等博客框架的 编译全站markdown 一样）。所以决定使用以下设置：
query_cache_size = 64M
query_cache_limit=3M在开启了 query_cache_size 以后，本站的平均页面生成时间（cpu负载100%）分布如下：
代码基于WordPress cache preload code (python3)，默认为2个线程。
但是对比一年前的记录来看，似乎还远远达不到一年前在腾讯云服务器上的水平，不知道到底是自然现象还是某个优化细节没注意到。
一年前的记录：（单线程）不同环境下的wordpress页面生成时间测试，如果使用litespeed server，大多数页面都是0.05~0.06秒生成的；即使使用apache/nginx，大多数页面生成时间也能在0.2秒左右。
2021-10-08：时隔接近一年，我再次用New Relic检查了一遍我的Wordpress环境，但没有发现什么特别异常的地方。想来想去总是觉得不太对，所以我把我的PHP彻底卸载并重装了一遍（和过去使用几乎一模一样的配置文件），突然之间页面的生成时间就降了一半：
懒得分析原因了，总之回到了原有速度。
2021-10-09：昨天无意中让PHP速度回到了正常水平，今天出于强迫症我还是选择重装系统，把NGINX, MariaDB和PHP换成了自己编译的版本（之前用的是编译好的安装包）。
2021-10-10：了解了一下HTTP/3和QUIC，所以希望本站也能支持这个新协议。Cloudflare提供了选项让我决定是否开启HTTP/3：
但这还不太够，我希望我的源站到Cloudflare edge server也能走HTTP/3协议。我开始学习并编译quiche:
GitHub - cloudflare/quiche: 🥧 Savoury implementation of the QUIC transport protocol and HTTP/3
同时在本地编译支持HTTP/3协议的 curl .
编译总体挺顺利，只是可惜目前官方只放出了Nginx 1.16.1的版本，有点落后进度了。但是到了套CF的时候，我发现无论我怎么努力，Cloudflare就是套不进我的HTTP/3 Nginx服务。后来我终于发现了不对：
看来努力是白费了。但这也让我发现了新的好处：因为从Cloudflare Edge到源站只支持 HTTP/1.1 ，所以（可能）传统的合并JS、CSS文件的优化方法还能继续使用。
2021-10-11：把MariaDB升级到 10.6.4 ，然后跑了3遍preload.py，平均页面生成时间又降了 0.01~0.02 。（当然这有可能是vps cpu频率浮动导致的）
2021-10-11：参考这篇文章：python - Making an executable in Cython - Stack Overflow，我把之前写的一个preload.py用cython和gcc编译成了可执行文件：
编译方法：（注：需要python3-devel；如果cython版本不为3.x，可能还需要把 --3str 参数去掉）
$ cython --embed --3str -o preload.c preload.py
或者
$ cython --embed -o preload.c preload.py
$ gcc -Os -I /usr/include/python3.6m preload.c -lpython3.6m -o preload运行时间提升如下（同一站点）：
修改前：preload.py运行时间大约为29~30s
修改后：preload运行时间大约为22~23s
实际情况：使用了一个月，并没有发现明显的性能提升
2021-10-15，有关我部署本博客的VPS：
3天前由于一时手贱，我不慎删掉了centos系统里的 site-packages 文件夹，后来干脆决定重装系统，试试其他的发行版。我决定使用 debian 11 作为新的OS，但却遇到了最为麻烦的事情：明明我的软件版本、各项设置都和之前的centos一致，但我的 平均页面生成时间 莫名其妙变高了：之前好不容易降到 0.21~0.22(s) ，现在却变成了 0.25~0.28(s) ，多次重装系统、重新编译都没有改善。最终我换回了centos，（尽管还是用相同的配置文件）指标又重新回到了之前的 0.21~0.22(s) 水平。
原因还没有搞明白，但不想再搞多次试验了（重装系统+重新编译等步骤通常要好几个小时），先这样吧==
后续更新：搞明白了，是编译pycurl惹的问题。见：🔗 [PycURL的性能取决于安装方法和编译依赖 - Truxton's blog] https://truxton2blog.com/pycurl-performance-differs/
2021-11-09：给mariadb升级到10.6.5（还是不敢尝试10.7.1 RC），nginx版本升到1.21.4
2021-11-15：用flask, fastapi和gofiber三种不同的框架编写同一个rest api后端服务，用loader.io测试了一下：gofiber的性能确实非常优越（高压力测试下的平均响应时间大概是fastapi的1/3）。尝到了golang的性能甜头以后我开始尝试使用golang重写一些之前用python写过的工具，比如 preload.py 。可惜短时间内没能学会goroutine的并发控制和golang屎一样的regex（不支持pcre！！！），这个计划暂时搁置了。
尽管golang重写的计划流产了，但还是对原来的代码进行了一些性能提升：比如对一串很长很长的字符串执行regex查找之前，可以用 str in text 这样的代码先判断是否存在。🔗 [python - What's a faster operation, re.match/search or str.find? - Stack Overflow] https://stackoverflow.com/questions/4901523/whats-a-faster-operation-re-match-search-or-str-find
11.23~11.26：在Vultr上面开了台机器，针对“本站在不同Linux发行版上的性能”做了几天娱乐测试，见：
2021-12-01：给preload.py换了一套执行逻辑：
修改前：
删除整个NGINX FastCGI缓存文件夹->执行preload.py
修改后：
删除单个url对应的FastCGI缓存文件->重新生成FastCGI缓存文件->操作下一个url ...
url和FastCGI文件的换算方法见：【半成品】NGINX FastCGI purge and preload for single URL .
2021-12-12：
我用代码换下了https://wordpress.org/plugins/ari-fancy-lightbox/，主要原因：
原插件的Fancybox 3版本略低；原插件加密了部分代码，导致很难在其基础上进行修改。
现在我把Fancybox升级到了3.5.7，并且对SVG的透明背景、thumbnail的排列位置等参数进行了调整。
2021-12-14：给pagination和每篇文章添加了←和→按键翻页的功能。
2021-12-15：效仿prism.js，给PDF.js嵌入页面添加了全屏按钮。
2022
2022-02-07：给nginx添加了pcre2和cloudflare-zlib的支持。pcre2可以下载官方release直接使用，cloudflare-zlib则需要git拉取并进行一点处理：
$ git clone https://github.com/cloudflare/zlib cf-zlib
$ cd cf-zlib
$ make -f Makefile.in distclean
# nginx编译参数里使用--with-zlib=/PATH/TO/cf-zlib2022-02-09：发现MariaDB发布了10.6.6，赶紧去编译更新了一份，结果今天就发现MariaDB把10.6.6临时取消回炉重做了（具体可见：🔗 [[MDEV-27789] mysql_upgrade / mariadb-upgrade in 10.6.6 is putting password in host argument - Jira] https://jira.mariadb.org/browse/MDEV-27789）
2022-02-14：升级到（修复了[MDEV-27789] bug的）MariaDB 10.6.7
2022-02-26：对本站数据库的压缩策略进行了调整：
调整前：有几个压缩率比较高的表使用了 PAGE_COMPRESSED = 1[grey]，但这些声明语句是MariaDB专有。
调整后：把上面提到的[grey]PAGE_COMPRESSED = 1[grey]全部去掉，但对[red]整个Wordpress数据库[/red]采用了lz4算法的[red]InnoDB Page Compression[/red]压缩：
[mariadb]
innodb_compression_default=ON
innodb_file_format='Barracuda'
innodb_default_row_format='dynamic'
innodb_compression_algorithm='lz4'具体可见：🔗 [InnoDB Page Compression - MariaDB Knowledge Base] https://mariadb.com/kb/en/innodb-page-compression/
现在整个数据库占用的存储空间大幅度降低（仅仅是原来的23.3%），但preload.py运行时间基本没有变化。
2021-02-28更新：经过几天的测试，我发现preload.py的运行时间稳定多了，比之前的表现（多次运行preload.py运行时间有30%~40%的差异）优秀太多。
2022-07-11更新：开启数据库全局压缩以后，所有表都会自动挂上PAGE_COMPRESSED=ON的表定义，这会导致mariadb mysqldump出来的数据库文件无法导入mysql（mysql不支持这个写法）。需要替换表定义里的特殊字段。见：🔗 [2022-07-12 - Truxton's blog] https://truxton2blog.com/2022-07-12/#有关MariaDB的page_compressed设置
2022-02-28：
更新了[grey]JetBrains-Mono 字体，从v6更新到了v11
2022-03-01：
偶然发现pdf.js放出了更新，所以把本站使用的pdf.js升级到了 2.13.216 .
2022-03-03：
给网站添加了一个加载条：🔗 [PACE — Automatic page load progress bars] https://codebyzach.github.io/pace/
我使用了Cloudflare提供的pace app（替代了Wordpress代码加载），这样可以把pace.min.js推到html header的最顶端。
2022-03-16：
NGINX编译使用的openssl升级到了1.1.1n .
2022-04 ~ 2022-05：
NGINX编译使用的openssl升级到了1.1.1o；
MathJax升级到了3.2.1；
pdf.js升级到了v2.14.305；
mariadb升级到了10.6.8；
本博客开始对chrome和firefox浏览器优先提供avif格式的图片，对safari和edge浏览器优先提供webp格式的图片。见：🔗 [制作avifenc-butteraugli docker镜像 - Truxton's blog] https://truxton2blog.com/create-avifenc-butteraugli-docker-image/
2022-05-24：
第一时间升级到了Wordpress 6.0；
本站不再使用插件 webp converter for media .
2022-05-25:
意外发现nginx更新了1.22.0版本，现在本站使用openssl 3和nginx 1.22.0.
2022-05-26:
揪出了PycURL的严重性能损失：PycURL的性能取决于安装方法和编译依赖 - Truxton's blog (truxton2blog.com)
2022-05-27:
从php 7.4.29迁移到php 8.0.19，除了一个不兼容的插件（search regex）以外，其他的功能都正常运作。
开启了opcache-JIT，再加上昨天揪出的PycURL性能问题，现在FastCGI的预加载速度大幅度提升。
唯一需要注意的是：开启JIT以后，给opcache分配的内存大概需要提升0.5~1.5倍。
2022-06-06:
开启了全站 scroll-behavior: smooth .
对本站JS/CSS进行减肥：不需要加载TOC、Popup Maker的一律dequeue，就像以前对 tex-svg.js 进行的操作一样。
2022-06-08:
MathJax升级到3.2.2.
2022-06-10:
php升级到8.0.20.
2022-06-22:
nginx openssl升级到3.0.4；
prismJS主题换成了coldark-cold；顺便修复了lang-css.js版本过老的问题。
2022-06-23:
本站之前部署在RHEL系linux上，imagemagick缺少对pdf的支持，上传的PDF没有preview thumbnail；
现在部署在Debian系linux上，可以生成pdf预览图了，重建了所有pdf preview thumbnail.
2022-06-29:
Nginx升级到 1.23.0 .
2022-07-06:
nginx openssl升级到 3.0.5 .
2022-07-07:
php升级到 8.0.21 .
2022-07-10:
认真考虑了一下本站到底该用什么方法来渲染嵌入PDF（目前有2种方法：浏览器原生支持，或者使用PDF.js）：
PDF.js / Firefox：目前使用的方法，但对部分重口味PDF的渲染效果不如chromium；
chromium原生：什么都好，就是不支持双指缩放；
Safari原生：锯齿过重，明显不如preview.app；
对比了不同PDF嵌入方案和渲染效果，还是决定继续使用PDF.js。具体对比内容见：🔗 [不同PDF查看器对PDF文件的渲染细节对比 - Truxton's blog] https://truxton2blog.com/different-pdf-viewers-render-effect/
2022-07-15:
libwebp升级到1.23
2022-07-19:
nginx升级到1.23.1
2022-07-28:
贼心不死，又一次向memcached和redis发起了preload.py时间测试。之前已经试过不止一次了，不知道为什么又要再来一次。
结果还是一如既往的失败，没有任何配置能打败sql query cache。具体结果见：🔗 [Memcached和Redis测试（preload.py） - Truxton's blog] https://truxton2blog.com/preload-py-memcached-redis-benchmark/
2022-07-31:
pdf.js升级到v2.15.349
2022-08-01:
preload.py新增逻辑：每次程序启动时都会先RESET query cache，然后再开始preload：这样也许能够提高一点sql让preload任务更加稳定。
同时，我把php-fpm的进程管理方式变成了on-demand.
2022-08-04:
php升级到8.0.22
* 更新：我注意到：（相同的配置文件）8.0.22的opcache缓存占用要比8.0.21小一些。（大概小6%左右）
* 更新2：我注意到：preload.py的速度要比以前快大约8% . 我猜测具体原因可能是：升级了php；RESET query cahce；php-fpm on-demand.
2022-08-06:
libwebp升级到1.24
2022-08-16:
Mairadb升级到10.6.9
2022-08-23:
prismJS升级到1.29.0
2022-08-28:
pdf.js升级到v2.16.105
2022-09-01:
php升级到8.0.23
2022-09-22:
Docker-avif使用的aom升级到3.5.0
升级了编译nginx使用的cloudflare-zlib
2022-09-30:
php升级到8.0.24
2022-10-11:
nginx-openssl依赖升级到3.0.6
2022-10-14:
Docker-avif使用的libavif升级到0.11.0
2022-10-20:
nginx升级到1.23.2
2022-10-21:
Docker-avif使用的libavif升级到0.11.1
2022-10-28:
php升级到8.0.25
2022-10-31:
pdf.js升级到3.0.279
2022-11-01:
编译nginx使用的openssl升级到3.0.7
2022-11-02:
本站升级到Wordpress 6.1，但升级后发现YARPP – Yet Another Related Posts Plugin直接罢工了。
解决方法是直接卸载这个插件了事。
其他功能似乎保持正常运作。
2022-11-04:
为了让nginx尽可能快速地随机读取硬盘小文件（主要是那些avif图片），我把 my.cnf 各项参数的数值基本上都砍了一半甚至更多（唯独保持了 query_cache_size = 40M 不变，因为这个太重要了），这样调整以后mariadb进程只占用了10%的RAM .
iowait是否真的改善了还有待查证，但很明确的一点是：preload.py性能完全没受影响，可见query cache的重要性。在此我又忍不住想要痛骂mysql 8.0移除了query cache的弱智决策。
2022-11-09:
mariadb升级到10.6.11
2022年11月：
陆陆续续折腾了一个月的nginx配置优化。 其实绝大部分“优化”工作都是在增大各种配置参数 ，我只是想让avif图片随机读取的速度更快一点！
2022-11-26:
pdf.js升级到3.1.81
2022-12-06:
nginx编译所使用的 PCRE2 升级到10.41
2022-12-03:
nginx编译所使用的 PCRE2 升级到10.42
2022-12-15:
nginx升级到1.23.3
2023
2023-01-01:
pdf.js升级到3.2.146
2023-01-05:
php升级到8.0.27
2023-01-13:
Docker-avif使用的libwebp升级到1.3.0
2023-01-24:
给PrismJS换了一个主题：🔗 [从零开始修改Dracula-PrismJS - Truxton's blog] https://truxton2blog.com/modify-dracula-prismjs/
根据highlightjs的git repo记录，highlightjs在2018年前后经历过一段断档，和现在PrismJS的处境极其类似...但好在后来highlightjs又找到了新的人接手，盘活了。现在PrismJS已经断气半年了，包括宣称“尚在开发中”的PrismJS v2也基本没动静...我再给半年的时间看看情况吧。如果真的死透了就切换到highlightjs那边去。
2023-01-29:
pdf.js升级到3.3.122，另外pdf.js的base64工具改成了postcss-url，详见：🔗 [pdf.js图标转换为base64格式 - Truxton's blog] https://truxton2blog.com/pdfjs-icon-to-base64/
2023-02-03:
从cloudflare-zlib切换回了普通的zlib .
2023-02-06:
mariadb升级到10.6.12
2023-02-07:
nginx编译使用的openssl升级到3.0.8
2023-02-08:
Docker-avif使用的aom升级到3.6.0
2023-02-14:
php升级到8.0.28
2023-02-20:
php 8.0寿命差不多到头了，准备考虑升级到php 8.1了，正在准备下一次全站测试
备注：2023-03-07测试完毕，应该是没有问题
备注2：后来又发现虽然没有error的问题，但有一堆warning的问题（都是wordpress core带来的），看着很不舒服，又降回来了。
2023-02-26:
pdf.js升级到3.4.120
2023-03-04:
好像是从去年开始，为了给avif/webp的硬盘读取速度让路（事实上这个思路似乎是有问题的），我把mariadb innodb buffer pool size 设置为一个很小很小的数值（32MB），但最近我发现我的wp-admin页面（包括那些登陆状态下的普通页面）打开得越来越慢。今天我把 innodb buffer pool size 重新设置成稍大一些的数值（128MB）：
解决了wp-admin页面打开速度过慢的问题；
avif/webp的小文件读取问题暂时丢在一边不管。事实上，Linux file cache应该不可能照顾到那些读取频率极低的非系统文件，升级服务器的硬盘配置才是硬道理。
2023-03-07：
本博客成功在php 8.1环境下运行，准备找个好时机迁移过去。
2023-03-07：
刚迁移到php 8.1就发现一堆warning，迁回php 8.0.28去了。
下次做迁移测试的时候还要多留个心眼注意一下debug.log .
2023-03-11：
使用WordPress-docker测试php 8.1环境下的Wordpress 6.2 RC1，这次没有Warning log了，所以不出意外的话本博客会在2023年3月底的时候迁移到php 8.1环境下的Wordpress 6.2 .
2023-03-14:
nginx编译使用的openssl升级到3.1.0
2023-03-19：
经过docker测试，Wordpress 6.2 beta在php 8.2环境下也能无error、无warning正常运行。但我目前计划的下一个php版本仍然是8.1 .
2023-03-28：
nginx升级到1.23.4
新的nginx有一个改动影响了我的配置文件：
*) Change: now nginx issues a warning if protocol parameters of a
http://nginx.org/en/CHANGES
listening socket are redefined.
所以我删掉了配置文件里重复定义的HTTPS配置项。
2023-03-29：
WordPress升级到了6.2，没有遇到什么问题。
过了3天后补充：我发现自从升级到6.2以后，运行preload.py所需要的mariadb query cache减少了整整4MB. 暂时不清楚这4MB是从哪里节约出来的。
2023-03-29：
WordPress升级6.2以后，我马上开始把PHP的环境从8.0.28升级到8.1.17，但最终还是没有成功。
使用的插件[Lazy Loader]在PHP 8.1环境下会出现deprecated warning.
还是要等一等，以后再考虑迁移吧。
2023-04-04：
pdf.js升级到3.5.141 有个恶心的报错，赶紧回滚到3.4.120去了
后续：
2023-04-06：这个恶心的报错确实是个bug，相关issue已经被解决但还没有放出下一个release，所以我简单修改了一下3.5.141的代码并开始使用这个版本。
2023-05-07：下一个release v3.6.172解决了这个问题。
2023-04-08：
过去1个星期我都在和fastcgi/tmpfs的一些机制周旋，试图优化当前的fastcgi访问速度。
如果问题能解决就写篇笔记回顾一下完整的过程以及尝试过的方案。
更新：最新的进度应该是：从tmpfs迁移到ramfs，并让nginx conf里的 keys_zone; max_size 管理fastcgi缓存文件夹的大小。
回顾笔记有待后续整理。
2023-04-11：
nginx 升级* 到1.24.0
*v1.24.0和v1.23.4的核心代码应该是一样的，只是从Mainline分支（1.23.x）变成了Stable分支（1.24.x）。
2023-04-14：
看到别人的Hexo博客有2个导航栏，我也想搞一个：
但是我在Wordpress插件市场找了一圈都没有找到一个特别适合自己的，所以干脆自己硬写一个好了：
在chatgpt的帮助下，本博客加入了一个新的导航栏：文章聚合！（没有文章聚合的时候会显示默认模版）
目前这些聚合在一起的文章id是手动一个一个 hard coding 到PHP代码里面去的，因为我实在是想不出什么特别好的方法省时省力，优化什么的以后再说吧。
2023-05-07：
pdf.js升级到3.6.172，之前的那个浮点数精度的问题解决了。
2023-05-12：
Docker-avif使用的aom升级到3.6.1
mariadb升级到10.6.13
2023-05-30：
pdf.js升级到3.7.107
2023-05-31：
nginx升级到1.25.0，编译nginx使用的openssl升级到3.1.1
2023-06-08：
mariadb升级到10.6.14
php升级到8.0.29
2023-06-13：
nginx升级到1.25.1
注意changelog提到了语法更变：" Feature: the "http2" directive, which enables HTTP/2 on a per-server basis; the "http2" parameter of the "listen" directive is now deprecated.".
所以需要修改配置语句：
listen (...) http2 (...) ;为
listen (...);
# 去掉listen里面的http2，单独拿出来作为http2 on
http2 on;在修改配置的过程中我还遇到了奇怪的 HTTP 421 Misdirected Request 问题，最后参考🔗 [amazon web services - 421 Misdirected Request using HTTP/2 and SAN SSL - Server Fault] https://serverfault.com/questions/772901/421-misdirected-request-using-http-2-and-san-ssl 解决了问题（在每个共享ssl证书的server里面都要写上 http2 on ; .
2023-06-30：
Docker-avif使用的libwebp升级到1.3.1，Docker镜像从Debian 11升级到Debian 12（Bookworm）
2023-07-02:
pdf.js升级到v3.8.162
2023-07-16：
本站从Debian 11升级到Debian 12
没有原地升级，老老实实开了个新的Debian 12服务器然后全站迁移过去的。
2023-07-16：
PHP 8.0系列EOF越来越近了，真的要考虑升级成php 8.1了
2023-07-22：
好久没用pdf-embed了，突然发现上传进去的pdf不给做缩略图了，赶紧到处乱回退版本试来试去（imagemagick支持的格式里面包含了PDF的，但不知道为什么pdf就是不给处理）
后来发现安装ghostscript就能用了： $ apt install ghostscript
但在去年的环境下（imagick 3.7.0，imagemagick 7.1.0-xx，Debian 11）我是不需要刻意安装ghostscript的，不知道为什么现在就需要了。
总之，当前（2023-07-22）图片处理那一套软件的版本为：imagick 3.7.0，imagemagick 7.1.1-13，Debian 12，ghostsciprt 10.0.0
2023-07-30:
pdf.js升级到3.9.179
2023-08-01:
nginx编译使用的openssl升级到3.1.2
2023-08-05:
php升级到8.0.30
2023-08-09：
升级到Wordpress 6.3
升级前后的nginx fastcgi数据对比：文章总数没有变化，但整体cache少了接近2MB，同时preload的时间少了2秒
暂时不知道是哪里减少的网页体积
2023-08-16：
nginx升级到1.25.2
2023-08-18：
nginx编译使用的zlib升级到1.3
2023-08-27:
pdf.js升级到3.10.111
2023-08-29：
发现libavif放出v1.0.0了，和aom v3.7.0-rc3一起编译通过了（原来的编译脚本和avifenc参数都能继续用）
等待aom v3.7.0正式版的放出
2023-09-01：
avif/webp Docker 版本升级：aom升级到3.7.0，libavif升级到1.0.1
2023-09-14：
avif/webp Docker 版本升级：libwebp升级到1.3.2
2023-09-19：
nginx编译使用的openssl升级到3.1.3
2023-09-27：
pdf.js升级到v3.11.174
2023-10-09：
之前遇到的「使用的插件[Lazy Loader]在PHP 8.1环境下会出现deprecated warning.」一直没有解决，考虑到php 8.0即将结束支持，升级是必须的了，所以我手动替换了html5-php的版本（之前出现warning的原因是插件[Lazy Loader]使用了较老的html5-php库，所以只需要把新的html5-php文件下载并覆盖即可），然后把php升级到了8.1.24
升级到php 8.1以后，preload.py的运行时间从php 8.0的57秒降到了50秒.
2023-10-24：
nginx升级到1.25.3；编译nginx使用的openssl升级到3.1.4
2023-10-29：
php升级到8.1.25
2023-11-05:
pdf.js升级到4.0.189 . 升级以后出现了类似 Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "application/octet-stream". Strict MIME type checking is enforced for module scripts per HTML spec. 的错误，解决方法是修改nginx的MIME配置文件：
application/javascript js;
# 修改为
application/javascript js mjs;2023-11-09:
wordpress-core升级到6.4.1 . 升级后出现了类似 PHP Deprecated: Function print_emoji_styles is deprecated since version 6.4.0! Use wp_enqueue_emoji_styles instead. 的报错，但考虑到这部分报错是由 wp-includes/functions.php 造成的，所以预计很快就会修复。
2023-11-13:
mariadb从10.6.5升级到10.11.6，尽管升级前在docker虚拟机里演练了很多次，但实战的时候还是出了意想不到的问题，lz4一直搞不定。后来终于解决了，见：🔗 [Mariadb 10.11 compression plugin的配置问题 - Truxton's blog] https://truxton2blog.com/mariadb-10-11-compression-plugin/
和之前的10.6.5看不出什么preload.py性能上的差别，两者运行的时间几乎一样，占用的query cache memory也几乎一样。
2023-11-18：
avif/webp Docker 版本升级：libavif升级到1.0.2
2023-11-21：
avif/webp Docker 版本升级：aom升级到3.7.1
2023-11-23：
NGINX编译使用的openssl升级到了3.2.0
2023-11-23：
php升级到8.1.26
写在2023-11-25：
不知道从什么时候开始，opcache占用的内存多了一点（明明我的插件数量很久没变化了），现在（在全站preload.py以及多数wp-admin页面访问以后）128MB的opcache内存已经占用107MB了（过去一般只有103MB到头）
后续：2024-01-03，把opcache分配内存增加到150MB.
2023-11-26：
pdf.js升级到4.0.269
2023-12-05：
avif/webp Docker 版本升级：libavif升级到1.0.3
2023-12-07：
avif/webp Docker 版本升级：aom升级到3.8.0
2023-12-22：
php升级到8.1.27
2023-12-31：
pdf.js升级到4.0.379
2024
2024-01-03：
发现opcache已经占用114/128 MB，是时候扩容了：现在给opcache分配了150MB内存。
（本站的wordpress插件已经差不多一两年没增加新的了，删插件倒是删了几个，只能说可能是全站.php代码量都有所增加导致的）
2024-01-23：
nginx编译使用的zlib升级到1.3.1
avif/webp Docker 版本升级：aom升级到3.8.1
2024-01-30:
nginx编译使用的openssl升级到3.2.1
2024-02-08：
mariadb升级到10.11.7
2024-02-08：
avif/webp Docker 版本升级：libavif升级到1.0.4
2024-02-14：
nginx升级到1.25.4
和cloudflare origin server brotli（🔗 [All the way up to 11: Serve Brotli from origin and Introducing Compression Rules] https://blog.cloudflare.com/this-is-brotli-from-origin）战斗了几个小时，依然没搞定，但还是把nginx的brotli打开来放在那里了（在此之前我都是编译不含brotli的nginx程序）
2024-02-16：
nginx编译使用的PCRE2升级到10.43（终于出了）
2024-03-13：
avif/webp Docker 版本升级：aom升级到3.8.2
2024-04-04：
wordpress-core升级到6.5
一切正常，暂时没有发现什么问题
2024-04-09：
nginx编译使用的openssl升级到3.3.0
2024-04-12：
pdf.js升级到4.1.392
2024-04-13：
php升级到8.1.28
正在考虑7月份之前把本站迁移到php 8.2
现在不是最优先的任务了。因为最近php修改了EOL政策，使得php 8.1的security support延长了一年。
具体可以见reddit的讨论：🔗 [PHP 8.1 EOL has changed? : r/PHP] https://www.reddit.com/r/PHP/comments/1cgw0r2/php_81_eol_has_changed/
2024-04-16：
nginx升级到1.25.5
2024-04-23：
在nginx的日志里检查出了 Accept-Encoding: gzip, br ，说明edge-to-origin brotli已经开始逐步推广使用了，以后默认编译带有brotli的nginx.
avif/webp Docker 版本升级：aom升级到3.9.0，libwebp升级到1.4.0
2024-04-24：
nginx升级到1.26.0
2024-04-29：
pdf.js升级到4.2.67
2024-05-29：
pdf.js升级到4.3.136
nginx升级到1.27.0
2024-06-04：
编译nginx使用的openssl升级到3.3.1
2024-06-06：
php升级到8.1.29
2024-06-08：
nginx编译使用的PCRE2升级到10.44
2024-06-10：
avif/webp Docker 版本升级：aom升级到3.9.1
2024-07-02：
pdf.js升级到4.4.168
2024-07-17：
wordpress-core升级到6.6
2024-07-31：
avif/webp Docker 版本升级：libavif升级到1.1.1
2024-08-09：
pdf.js升级到4.5.136
2024-08-16：
nginx升级到1.27.1
2024-08-30：
avif/webp Docker 版本升级：aom升级到3.10.0
2024-09-03：
pdf.js升级到4.6.82
编译nginx使用的openssl升级到3.3.2
2024-09-29：
php升级到8.1.30
2024-10-03：
nginx升级到1.27.2
把maraidb query cache从40M增加到了50M.
2024-10-07：
pdf.js升级到4.7.76
mariadb my.cnf的max_allowed_packet从原本的1M提升到256M（我也不知道原本为什么会设置成这么小的一个数字）
mariadb从10.11.7升级到11.4.3，迁移过程中没有遇到什么问题，原本的mariadb编译指令以及my.cnf配置文件都可以直接用。
2024-10-13：
服务器的python环境从python 3.11升级到3.12（本站很多后台功能都是用python写的，比如这个基于python3的多线程WordPress缓存预加载代码
）
2024-10-17：
先是直接把mariadb query cache size从50M降到了10M（然后还尝试了1M和0M），具体原因和性能测试结果写在🔗 [Memcached和Redis测试（preload.py） - Truxton's blog] https://truxton2blog.com/preload-py-memcached-redis-benchmark/：
但是最后还是把query cache size设置回了50M，原因是：目前，服务器分配的内存完全没必要在这几十MB上面纠结。
可能等到以后query cache开销大了再考虑降低分配量吧。
2024-10-23：
nginx编译使用的openssl升级到3.4.0（过了几天降级回去了，见下面一条）
2024-10-27：
由于突然出现图片懒加载http 522错误（每一页笔记都会有随机几张图片中招），怀疑是最近升级的openssl 3.4.0搞的鬼，所以把nginx编译使用的openssl降级到3.3.2再观察一段时间试试。
2024-11-03：
pdf.js升级到4.8.69
2024-11-10：
关于前几天对nginx openssl版本的降级：今天又把openssl重新升级为了3.4.0 . 编译好了以后测试了几个页面发现貌似没有出现http 522错误了，准备再用几天看看是不是稳定。
2024-11-13：
wordpress-core升级到6.7.0
升级前后的fastcgi缓存大小完全一致，所以我认为前端方面应该是没什么变化
2024-11-18:
avif/webp Docker 版本升级：aom升级到3.11.0
2024-11-20：
nginx openssl 3.4.0用着还是怪怪的（没有出明显的问题，但体感一些页面响应时间增加），还是降级回openssl 3.3.2了
2024-11-21：
wordpress升级到6.7.1
2024-11-22：
php升级到8.1.31
2024-11-28：
nginx升级到1.27.3（openssl还是保持3.3.2不变）
2024-12-02：
pdf.js升级到4.9.124
2024-12-06：
pdf.js升级到4.9.155
2024-12-20:
avif/webp Docker 版本升级：libwebp升级到1.5.0
