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.2022-05-27更新：为什么有的时候Debian系拥有显著的性能损失？因为安装了性能低下的PycURL！详见：🔗 [PycURL的性能取决于安装方法和编译依赖 - Truxton's blog] https://truxton2blog.com/pycurl-performance-differs/
本文从2021-11-22的草稿里分离整理出来。
去年进行过类似娱乐测试，但比较的是Apache, Nginx和Litespeed，见：（单线程）不同环境下的wordpress页面生成时间测试
有关preload的代码见：WordPress cache preload code (python3) - Truxton's blog . 后来我又对这篇文章的preload.py进行了修改，统计网页底部的页面生成时间并取平均数，和preload.py总运行时间放在一起，作为最后统计的结果。长期以来，我一直用它来衡量LEMP的整体性能（尽管并不严谨）。
它经历了以下变化：（同一台VPS）
| 状态 | preload大致性能（越低越好） |
| 不知道为什么，安装了一个性能极低的PHP，很长一段时间都没有发现 （见：博客设计与部署 修改记录（2021-09开始）） | 0.5s左右 |
| 安装了正常性能（大概）的PHP，追上了一年前在腾讯云上测试的结果 | 0.22s左右 |
| 尝试从centos 8切换到Debian 11 | 0.28s左右，很失败 |
| Debian 11很失败，切换到centos 7（考虑到centos 8的end of life） | 0.22s左右 |
| 又一次作死，尝试切换到RHEL 8.5 | 0.28甚至0.35甚至0.47，非常非常失败 |
| RHEL 8.5很失败，切换到RHEL 7.9 | 回到了正常水平（0.22s左右） |
| 仍在觊觎更高内核版本的linux发行版， 希望能够在redhat 8.5这样的平台上跑出更高水平（<0.22s） | 打算尝试RHEL 7, RHEL 8, CentOS Stream, Fedora 35, Debian 11 |
听说RHEL个人版免费了，总是手痒想切换到RHEL 8.5。这两天手贱尝试了一次，发现preload.py性能特别特别差劲，不得不切回去（没有切回原先的CentOS 7.9而是切回了RHEL 7.9），preload性能又回到了原来的水平。前一个月我也遇到过类似的情况（从CentOS 8切换到Debian 11.1性能反而从0.23下降到0.28）。鉴于preload的代码性能比较稳定（用了一个多月，有较多数据支撑），所以打算开一个Vultr $6/m的服务器单独测试各大Linux发行版的preload性能。（不敢在唯一的服务器上测试了，每次测试网站都会离线小半天）
附：在这里查找Linux发行版的end of life：https://endoflife.date/
除了Linux发行版不同以外，其他的参数都尽量保持一致，包括nginx/php/mariadb/python/cython/pycurl...的版本。Python的版本跟随各大发行版的默认Python版本（比如RHEL 7.9/8.5使用的都是python 3.6.8，而Fedora 35是3.10），因为要使用python3-devel .
| 主机 | 安装的linux发行版 | 平均preload （单位：秒；越低越好） | 总时间 |
| 当前使用的VPS（超售严重） | CentOS 7.9 | 0.22~0.24 | |
| 当前使用的VPS（超售严重） | Redhat Enterprise Linux 8.5 | 0.27, 0.29, 0.37, 0.35... （很糟糕） | |
| 当前使用的VPS（超售严重） | Redhat Enterprise Linux 7.9 | 0.22~0.24 | |
| Vultr (High Frequency $6/m) | Redhat Enterprise Linux 7.9 | 0.195~0.200 | 22~23 |
| Vultr (High Frequency $6/m) | Redhat Enterprise Linux 8.5 | 0.175~0.180 | 21~22 |
| Vultr (High Frequency $6/m) | Fedora 35 | 0.18~0.20 | 22~24 |
| Vultr (High Frequency $6/m) | Debian 11 | 0.13~0.14（看下面的解释） | 25~26 |
| Vultr (High Frequency $6/m) | CentOS Stream | 0.18~0.19 | 22~23 |
Debian 11是非常离谱的：虽然平均页面生成时间莫名其妙降到了0.13~0.14，但仔细一看就会发现preload.py的运行总时间仍然很高（甚至高于RHEL 7/8的运行总时间）。所以只能暂时把它归结于php编译出现了问题导致wordpress计算时间的方法出了问题。
Vultr上面的测试跑得差不多了，我又回到了之前使用的VPS，试图复现Vultr跑出的结果：
结果很失败，见下表：
续表：
| 状态 | preload大致性能（越低越好） |
| ...... | ...... |
| 跑到Vultr上面开新机器测试了两天， 自以为掌握了什么神奇的规律（在Vultr上面，Redhat 8.5表现最好） | Vultr上面的性能（总结）： Redhat 8.5 > CentOS Stream > Fedora 35 ≈ Redhat 7.9 > Debian 11 |
| 回到原来的VPS，先安装了Redhat 8.5 | 还是很失败，0.28上下浮动 |
| 不信邪，尝试CentOS Stream | 还是很失败，0.28上下浮动 |
| 只能切换回Redhat 7.9了 | 又神奇地回到了原来的0.22左右的水平 |
想破了头也没想出到底是什么导致了在当前VPS上，Redhat 8.5性能很差（更确切地说，凡是用了Kernel 4.x/5.x的Linux发行版的性能都很差），和Vultr几乎反了过来。只能暂时归咎于“当前VPS硬件比较老，不太匹配新内核”这种自圆其说的解释了。（事实上，当前VPS主机使用的KVM内核为：RHEL 6.6.0 ）
累了累了，目前在回到了Redhat 7.9，暂时不想做新的实验了。
但由于Debian 11在本次测试中表现异常，为了今后不被类似因素干扰，我决定修改preload.py的页面生成时间获取逻辑，现在不从wordpress-php那里获取了，改为获取pycurl的响应时间：
# c = pycurl.Curl()
# some code to build pycurl
start = time.time()
c.perform()
end = time.time()