部署AppRTC服务

AppRTC是WebRTC视频通话的服务程序，一般可以将其作为参考实现，搭建AppRTC服务受限于很多条件，并不是太容易。在参考了官方操作和大量的博客之后，根据自己操作实践排除了很多网络博客上的错误方法，终于部署成功了一套环境。测试环境为阿里云的CentOS 7服务器，带公网IP和域名。

部署前的必要条件

部署前，首先要明确的是必要的依赖环境，必须满足以下需求：

公网服务器，如果非公网就只能在局域网玩玩了，此处暂不讨论局域网
SSL证书，因为WebRTC必须在HTTPS环境下使用，因此通信WebSocket也必须支持

如果没有证书，但是有域名的话，可以去申请免费的证书，具体百度 Let’s Encrypt。本博客使用了Caddy服务器，此服务器可自行自动申请其证书，其证书存放在

/var/lib/caddy/acme/acme-v02.api.letsencrypt.org/sites/

下，按站点域名存放，假设本次部署使用的 example.com 域名，对应 8.8.8.8，其证书存放在

/var/lib/caddy/acme/acme-v02.api.letsencrypt.org/sites/example.com/

下，包含公钥文件 example.com.cert 和私钥文件 example.com.key 文件。

上面的 example.com 和 8.8.8.8 是域名和对应的IP，此处为举例，抹去了我的真实的地址。

安装编译环境

除了必要条件外，编译安装相关源码也需要一些编译环境，已知目前最终部署的程序为

apprtc GAE的Python和NodeJS开发的房间服务器
collider golang开发的信令服务器
coturn c语言开发的stun/turn服务器

系统基础环境安装

因为上面的依赖以及后续使用发现，系统需要安装的依赖环境如下（已经安装了跳过）

yum install python #要求2.7版本
curl -sL https://rpm.nodesource.com/setup_10.x | bash – #安装比较高的10版本
npm -g install grunt-cli #grunt工具
yum install gcc-c++ make #C/C++编译器等
yum install golang #golang编译器
yum install java-1.8.0-openjdk #安装JDK，我选择了1.8版本
yum install libevent-devel #编译coturn需要
yum install git #可以下载Github源码
yum install sqlite-devel #编译coturn需要

GAE环境安装

准确的讲需要安装的是 Google app engine SDK for Python，但是因为众所周知的原因，我们并不能直接访问，但是我从其他地方获知了一个比较老的下载地址，可以离线安装，而且是可以下载的

wget https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-188.0.1-linux-x86_64.tar.gz

虽然这个是Google Cloud SDK，但是我发现确实是可以用，并且可以更新，估计是现在进行了整合吧

tar xzvf google-cloud-sdk-188.0.1-linux-x86_64.tar.gz
./google-cloud-sdk/bin/gcloud components update

这其中因为 AppRTC 是用GAE的Python开发的，依赖Python 2.7环境。据说现在支持了3.7版本了，因为不能上官网，不确定。

编译构建版本

编译coturn

因为coturn是必须依赖的组件，我们优先处理这个，这个软件并不在仓库中，其依赖的libevent的版本与仓库中的一致，并不需要单独编译，因此只需要下载编译这个软件即可

因为这个软件中带了RPM的构建脚本，因此我这里打算进行RPM包的构建，首先安装RPM构建工具

yum install rpm-build

开始下载源码进行编译构建安装包

wget https://github.com/coturn/coturn/archive/4.5.1.1.tar.gz
mkdir -p ~/rpmbuild/SOURCES
mv 4.5.1.1.tar.gz -p ~/rpmbuild/SOURCES/turnserver-4.5.1.1.tar.gz
rpmbuild -ta ~/rpmbuild/SOURCES/turnserver-4.5.1.1.tar.gz

等构建成功后，会在 ~/rpmbuild/RPMS/x86_64 目录下发现好几个安装包，只需要安装 turnserver 即可

rpm -ivh ~/rpmbuild/RPMS/x86_64/turnserver-4.5.1.1-0.el7.x86_64.rpm

如果怕编译麻烦的，可在本站下载编译好的包进行安装

rpm -ivh https://cdn.xilixili.net/linux/turnserver-4.5.1.1-0.el7.x86_64.rpm

至于配置，我们后面再讲。

编译collider

Collider是Go开发的服务，依赖websocket，依然不能访问其地址。因此只能下载镜像安装，此处以将Go的环境设置的当前用户目录下的go目录为例说明。另外Collider的代码在AppRTC之中，因此此处就直接下载AppRTC的源码了，后续不需要下载了。

export GOPATH=$HOME/go
mkdir -p ~/go/src
git clone https://github.com/apprtc/apprtc
ln -s `pwd`/apprtc/src/collider/collider $GOPATH/src
ln -s `pwd`/apprtc/src/collider/collidermain $GOPATH/src
ln -s `pwd`/apprtc/src/collider/collidertest $GOPATH/src
mkdir -p $GOPATH/src/golang.org/x
cd $GOPATH/src/golang.org/x
git clone https://github.com/golang/net.git
go get collidermain
go install collidermain

至此，程序编译好并且安装到了 $GOPATH/bin 下面。

配置启动服务

注意，下面所有提供网络的服务，要注意防火墙配置，特别是UDP端口，测试平台关闭了防火墙。

配置启动coturn

首先需要生成签名证书

mkdir /cert
openssl req -x509 -newkey rsa:2048 -keyout /cert/turn_server_pkey.pem -out /cert/turn_server_cert.pem -days 99999 -nodes

然后再生成用户，以 apprtc 为例

turnadmin -k -u apprtc -p apprtc

执行之后会生成一个key，记住这个key，马上要用到。编辑 /etc/turnserver/turnserver.conf 文件，这个文件大部分的功能都默认是注释的，因此基本找到出处进行修改，大概如下

listening-ip=8.8.8.8
listening-port=3478
relay-ip=8.8.8.8
tls-listening-port=5349
external-ip=8.8.8.8
Verbose
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=apprtc
user=apprtc:0x949534a397bcf2e88470c86ad3749d9c（替换成上面的key）
user=apprtc:apprtc
cert=/cert/turn_server_cert.pem
pkey=/cert/turn_server_pkey.pem

保存之后，启动服务

systemctl enable turnserver
systemctl start turnserver

注意，很多教程说要配置 TRUN REST API，即自己需要实现个REST API服务，让AppRTC进行查询获取，通过分析和测试，发现第一这个服务必须是POST请求的，具体格式参考标准，第二是并不需要这个API也能正常使用，因此请不要折腾REST API了。

启动Collider服务

暂时以测试为主，后续可为此程序编写添加个systemd服务。

此服务需要对外提供WSS服务，因此需要证书，将之前的域名证书拷贝过去即可

cd /var/lib/caddy/acme/acme-v02.api.letsencrypt.org/sites/example.com/
cp example.com.cert cert.pem
cp example.com.key key.pem
chmod 755 /cert/*

然后通过下面的命令启动服务

./collidermain -port=8089 -tls=true -room-server=”http://example.com:8080″

注意，我们设置的这个服务的端口是8089端口，AppRTC默认的HTTP端口是8080，HTTPS端口是8081，但是实际测试中发现AppRTC在使用HTTPS的时，会经常SSL异常，未查明原因。

配置启动AppRTC

配置AppRTC的配置文件 ~/apprtc/src/app_engine/constants.py 文件如下(仅列出修改项)

ICE_SERVER_OVERRIDE = [
{
“urls”: [
“turn:8.8.8.8:3478?transport=udp”,
“turn:8.8.8.8:3478?transport=tcp”
],
“username”: “apprtc”,
“credential”: “0x949534a397bcf2e88470c86ad3749d9c” #替换成上面的key
},
{
“urls”: [
“stun:8.8.8.8:3478”
]
}
]

ICE_SERVER_BASE_URL = ”
ICE_SERVER_URL_TEMPLATE = ”
ICE_SERVER_API_KEY = os.environ.get(‘ICE_SERVER_API_KEY’)

# Dictionary keys in the collider instance info constant.
WSS_INSTANCE_HOST_KEY = ‘example.com:8089’
WSS_INSTANCE_NAME_KEY = ‘vm_name’
WSS_INSTANCE_ZONE_KEY = ‘zone’
WSS_INSTANCES = [{
WSS_INSTANCE_HOST_KEY: ‘example.com:8089’,
WSS_INSTANCE_NAME_KEY: ‘wsserver-std’,
WSS_INSTANCE_ZONE_KEY: ‘us-central1-a’
}]

上面的配置已经可以保证使用了，且在命令行指定SSL证书后，就能提供服务了，但是由于之前提到了SSL异常问题，即使在切换到HTTP之后并使用nginx代理后，出现了URL不匹配的错误，因此还不能直接使用，为了解决上面的问题，我修改了代码，首先配置 ~/apprtc/src/app_engine/constants.py 修改

REDIRECT_URL = ‘https://example.com:9090’

这里假设nginx代理的地址是 example.com:9090 ，然后修改该目录下的 apprtc.py 文件，大概在300行左右，修改其中room_link的赋值为

room_link = constants.REDIRECT_URL + ‘/r/’ + room_id

然后编译代码并运行代码，命令如下

cd ~/apprtc
grunt build
cd ~
google-cloud-sdk/bin/dev_appserver.py –host example.com ~/apprtc/out/app_engine/ –dev_appserver_log_level debug

会看到输出显示

Starting module “default” running at: http://example.com:8080

也就是意味着服务提供的地址是 http://example.com:8080

安装配置nginx代理

如上，使用nginx代理https请求，端口为 9090，直接yum安装

yum install nginx

配置 /etc/nginx/nginx.conf 文件

#server {
# listen 80 default_server;
# listen [::]:80 default_server;
# server_name _;
# root /usr/share/nginx/html;

# # Load configuration files for the default server block.
# include /etc/nginx/default.d/*.conf;

# location / {
# }

# error_page 404 /404.html;
# location = /40x.html {
# }

# error_page 500 502 503 504 /50x.html;
# location = /50x.html {
# }
#}

server {
listen 9090 ssl default_server;
server_name example.com;
ssl_certificate “/cert/cert.pem”;
ssl_certificate_key “/cert/key.pem”;
location /{
proxy_pass http://example.com:8080;
proxy_set_header Host $host;
}
}

配置默认注释了原来默认配置的80端口的配置，添加了一个9090的代理服务，配置之后启动服务

systemctl enable nginx
systemctl start nginx

体验测试

通过 https://example.com:9090 访问AppRTC服务

再找另外一个用户同时打开浏览器，输入相同的号码并JOIN，即可实现视频通话。

另外在目录下的~/apprtc/src/web_app/html/params.html网页中自定义了一些配置参数，可以在URL中自定义WebRTC的参数，比如打开高清摄像头、关闭音频等等，具体参考这个页面即可。

采用默认配置测试后，个人使用感觉效果如下

语音很清晰无噪音，两个用户使用手机外放离的很近的时候，可能是回声消除的原因会出噪音
视频感觉效果一般般，带宽占用也不高，毕竟是P2P模式，但并不是特别清晰
整体感觉和微信视频差不多，可能稍好一点
并没有找到测试turn的环境，这个环境下的效果不清楚

手机微信也可以的哦。

使用Intel CS for WebRTC 4.2.1 搭建实时音视频通讯系统

Intel CS for WebRTC 升级到4.2.1后，需要的软件包进行了更新，安装过程中一些小的细节也需要注意一下。

1.操作系统：

CentOS* 7.6, Ubuntu 18.04 LTS，本次测试，我使用的Ubuntu 18.04 LTS。

2.手动安装依赖包

node.js 8.15.0，貌似仅支持这个版本。

下载：https://nodejs.org/dist/v8.15.0/node-v8.15.0-linux-x64.tar.gz

解压并安装：

tar -xzvf node-v8.15.0-linux-x64.tar.gz

mv node-v8.15.0-linux-x64 /opt/
ln -s /opt/node-v8.15.0-linux-x64/bin/node /usr/local/bin/node
ln -s /opt/node-v8.15.0-linux-x64/lib/node_modules/npm/bin/npm-cli.js /usr/local/bin/npm

3.下载 Intel CS for WebRTC，需要先登录，如果没有注册，先注册。在页面上点击下载：

或者直接下载：

wget http://registrationcenter-download.intel.com/akdlm/irc_nas/15608/Intel_CS_WebRTC.v4.2.1.zip

4.解压后包括如下文件：

再解压对应的MCU文件，得到Release-v4.2.1的目录。

5.开始安装

cd Release-v4.2.1

bin/init-all.sh –deps –software

我使用的软件编码，如果有Intel硬件编码芯片，可以使用hardware。

在安装的过程中，会提示mongodb的账户等信息，所有提示都直接回车即可。

6.配置对外服务IP

如果服务直接配置了对外服务的IP，请跳过本步；如果使用的虚机有EIP，需要配置对外服务的IP，假设对外服务IP为120.92.100.101（下同）。

vi webrtc_agent/agent.toml

修改：

network_interfaces = []

为：

network_interfaces = [{name = “eth0”, replaced_ip_address = “120.92.100.101”}]

vi portal/portal.toml

修改：

ip_address=””

为：

ip_address=”120.92.100.101”

7.配置UDP通讯端口

如果是虚机，在虚机网络管理中打开UDP的可访问端口，推荐范围2000-9000，同时需要在配置文件中进行配置。

vi webrtc_agent/agent.toml

修改：

# The webrtc port range

maxport = 0 #default: 0

minport = 0 #default: 0

为：

# The webrtc port range

maxport = 9000 #default: 0

minport = 2000 #default: 0

8.打开TCP通讯端口

如果是虚机，在虚机网络管理中打开TCP和UDP的可访问端口，推荐范围2000-9000

9.关闭防火墙(需要管理员权限)

ufw disable

10.启动 Intel CS WebRTC

./bin/start-all.sh

如果没有报错，表示启动功能，并最后看到下面的字样：

1 rooms in this service.

sampleRoom Id: XXXXXXX

11.在手机上，通过Chrome浏览器，使用默认room进行音视频通话

https://120.92.100.101:3004/

成功后，会看到两个窗口，上面是本地的采集窗口，下面是视频通讯的多窗口

如果没有正常显示，可以通过Chrome浏览器的开发工具查看具体的原因。

12.使用另外一台手机，或者把链接发给你的朋友，使用Chrome浏览器打开链接，就可以进行视音频通话了。

mysql5.7关闭ONLY_FULL_GROUP_BY

mysql5.7以上版本在常会报关于only_full_group_by的错误，可以在sql_mode中关闭他，网上查找的解决办法通过实践后发现有些不详细，关键地方说的不清楚，有的有些错误，自己解决之后在这里总结一下。

操作系统：Linux
mysql版本：5.7.26
查看
进入mysql 查看mysql版本：select version();

运行SELECT @@GLOBAL.sql_mode;和SELECT @@SESSION.sql_mode;查看sql_model参数，可以看到参数中有ONLY_FULL_GROUP_BY，

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
1
2
临时去除ONLY_FULL_GROUP_BY
因为这种方式从参考资料上来看只是临时去除，所以，我并没有尝试，这里列出解决办法：

set @@GLOBAL.sql_mode=”;
set sql_mode =’STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION’;
1
2
修改配置文件去除ONLY_FULL_GROUP_BY
这种方式是我实践的方式，我详细说一下：

打开配置文件mysql.cnf
sudo gedit /etc/mysql/mysql.cnf
1
在[mysqld]中添加代码
sql_mode =’STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION’
1
网上有很多资料写到这段代码在[mysql]中也同时添加，另外有些写着添加内容为 “set sql_mode XXXX”经过我在自己机器上验证，发现都是不行的，只能在[mysqld]添加，否则会造成mysql无法连接

验证是否生效
重启mysql

sudo service mysql restart
1
查看参数是否存在

mysql> SELECT @@sql_mode;
+————————————————————————————————————————+
| @@sql_mode |
+————————————————————————————————————————+
| STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+————————————————————————————————————————+
1 row in set (0.00 sec)

mysql> SELECT @@GLOBAL.sql_mode;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect…
Connection id: 2
Current database: *** NONE ***

+————————————————————————————————————————+
| @@GLOBAL.sql_mode |
+————————————————————————————————————————+
| STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+————————————————————————————————————————+
1 row in set (0.00 sec)

mysql> SELECT @@GLOBAL.sql_mode;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect…
Connection id: 2
Current database: *** NONE ***

CentOS 7增加ifconfig命令

今天安装了centos7，也习惯了最小化安装，装完发现ifconfig 这个命令没有。

据说ifconfig命令已经过时了，而且在最小化版本的RHEL 7以及它的克隆版本CentOS 7，Oracle Linux 7和Scientific Linux 7中也找不到该命令。

最小化安装后，可以用 ip addr 命令查看网络信息。

那么习惯ifconfig的用户，则需要yum -y install net-tools即可

centos 7 下haproxy的配置文件详解及haproxy优化

HAProxy虽然名字前有HA，但它并不是一款高可用软件，而是一款用于实现负载均衡的软件，可实现四层与七层的负载均衡。

关于haproxy的常用调度算法，可以参考博文：Haproxy支持的调度算法。

haproxy的详细配置过程和配置日志记录，可以参考博文：keepalived+Haproxy搭建高可用Web群集。

这篇博文不谈如何配置haproxy，主要来聊一下它的配置文件说明以及生产环境中的参数调优。

haproxy的配置文件通常分为三个部分：global、defaults和listen。依次为全局配置、默

认配置、应用组件配置。

global配置：

global
        log 127.0.0.1   local   #配置日志记录，local0为日志设备，默认存放到系统日志
        log 127.0.0.1   local1 notice  #notice为日志级别，通常有24个级别
        #log loghost    local0 info
        maxconn 4096             #最大连接数
        chroot /usr/share/haproxy         #该服务自设置的根目录，一般需将此行注释掉
        uid 99         #用户UID
        gid 99        #用户GID
        daemon        #守护进程模式

defaults配置项配置默认参数，一般会被应用组件继承，如果在应用组件中没有特别的声明，将安装默认配置参数：

defaults
        log     global               #定义日志为global配置中的日志定义
        mode    http                 #模式为http
        option  httplog              #采用http日志格式记录日志
        option  dontlognull
        retries 3         #检查节点服务器失败次数，连续达到三次失败，则认为节点不可用
        redispatch             #当服务器负载很高时，自动结束当前队列处理比较久的连接
        maxconn 2000                      #最大连接数
        contimeout      5000              #连接超时时间
        clitimeout      50000             #客户端超时时间
        srvtimeout      50000             #服务器超时时间

listen配置项一般配置应用模块参数：

listen  appli4-backup 0.0.0.0:10004           #定义一个名为appli4-backup的应用
                option  httpchk /index.html        #检查服务器的index.html文件
                option  persist     #强制将请求发送到已经down掉的服务器，一般禁用此选项。
                balance roundrobin        #负载均衡调度算法使用轮询算法
            server  inst1 192.168.114.56:80 check inter 2000 fall 3     #定义在线节点
         server  inst2 192.168.114.56:81 check inter 2000 fall 3 backup #定义备份节点
#注意：在以上定义备份节点的参数中，
#“check inter 2000”表示haproxy服务器和节点之间的一个心跳频率，
#“fall 3”表示连续三次检测不到心跳频率则认为该节点失效。
#节点配置后带有“ backup”表示该节点只是个备份节点，只有主节点失效该节点才会上。
#去除backup，表示为主节点，和其他主节点共同提供服务。
haproxy的负载均衡参数说明：

权威的5.6、7.0、7.1、7.2、7.3和7.4 PHP基准性能测试（2020）

每年，我们都会在各种平台上发布深入的性能基准测试，以了解不同版本的PHP如何相互竞争。这次我们再次全力以赴，将22个不同平台/配置的6个不同PHP版本标记为基准;包括WordPress，Drupal，Joomla！，Laravel，Symfony等。我们还测试了流行的电子商务解决方案，例如WooCommerce，Easy Digital Downloads，Magento，Grav CMS和October CMS。

我们一直在鼓励WordPress用户利用最新支持的PHP版本。它们不仅更安全，而且还提供了其他性能改进。我们也不是只在谈论WordPress，这在所有平台上都是如此。今天我们将向您展示PHP 7.4如何帮助我们克服一切挑战！ ?

我们在6个不同的PHP版本上测试了22个平台/配置的性能，而#PHP 7.4在17/17（5 N / A）上获得了金牌。 ??

点击鸣叫

社区和Kinsta中PHP的状况

PHP是一种开放源代码的服务器端脚本和编程语言，主要用于网络开发。大部分WordPress核心软件都是用PHP编写的，这使PHP成为WordPress社区非常重要的语言。

只需移至Kinsta，即可将WordPress网站的速度提高200％。

今天免费迁移

有人可能会争辩说PHP已经死了。但是，即使开发人员喜欢声明这一点，PHP仍然比以往更活跃，更快，更好。根据W3Techs的说法，使用服务器端编程语言的所有网站中有超过78.9％使用PHP。那是很多依赖PHP的网站。

但是，社区中的一个大问题是，许多人仍在使用旧的不受支持的PHP版本。根据WordPress统计，仅38.3％的版本在受支持的PHP版本（7.2或更高版本）上运行。这引入了性能和安全性问题。

为什么会这样呢？以下是一些我们通常会看到的常见原因：

缺乏对社区进行有关PHP是什么及其在WordPress如何发挥作用方面的重要作用的教育。并非每个人都精通技术，这还可以。
在较新版本的PHP上运行的插件和主题的兼容性问题。
WordPress托管提供商不愿推出新版本，因为担心会出现问题。

为了尝试帮助社区向前发展，Kinsta采用了与PHP相同的寿命终止（EOL）时间表。这有助于确保您的WordPress网站尽可能快且安全。

Kinsta客户如何与普通WordPress社区对抗？我们自己很好奇，所以我们看了一些数字。

Kinsta托管的网站的PHP版本

这是摘要：

Kinsta的WordPress网站中有25.8％运行的是PHP 7.2。
Kinsta上有68.6％的WordPress网站正在运行PHP 7.3。
Kinsta的4.7％WordPress网站都在运行PHP 7.4。
我们正在努力实现最终的<1％。 ?

我们为发现这些数字感到骄傲和兴奋。这意味着Kinsta客户中PHP的采用率非常高！远远高于一般的WordPress人口。

在Kinsta托管的所有WordPress网站中，高达73.3％运行的是PHP 7.3或更高版本！ ?

点击鸣叫

PHP基准测试（2020）

即使不再正式支持PHP 5.6、7.0和7.1，仍然有许多WordPress网站在运行。因此，我们决定测试所有六个不同的PHP版本，以便您可以看到较新的版本可以在性能方面给您带来多少好处。

对于每个测试，我们使用每个平台的最新版本，并以15个并发用户为基准对主页进行一分钟的基准测试。以下是我们测试环境的详细信息。

使用的计算机：英特尔（R）至强（R）CPU（30 CPU，120 GB RAM，1TB SSD）。这是由Google Cloud Platform提供支持的“计算优化”（C2）计算机，在隔离的容器中运行。所有Kinsta托管计划都提供C2机器。
操作系统：Ubuntu 18.04.3 LTS（GNU / Linux 5.0.0-1026-gcp x86_64）
堆栈：Nginx 1.17.6，MariaDB 10.4.10
PHP版本：5.6、7.0、7.1、7.2、7.3、7.4。
注意：在某些CMS / Frameworks中，我们还安装了其他PHP软件包以满足其新要求或Composer依赖项要求。
页面缓存：在所有配置和平台上均禁用。
OPcache：对于WordPress，Joomla和Drupal，我们使用了官方的Docker映像。其余的我们使用相同的映像设置，并使用以下推荐的php.ini设置启用了OPcache，但opcache.max_accelerated_files的值从4,000增加到50,000。

opcache.memory_consumption = 128
opcache.interned_strings_buffer = 8
opcache.max_accelerated_files = 50000
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1
opcache.enable_cli = 1

OPcache通过将预编译的脚本字节码存储在共享内存中来提高PHP性能，从而消除了PHP在每个请求上加载和解析脚本的需求。

这些测试是由Kinsta的WordPress贡献者和Web开发人员Thoriq Firdaus执行的。

经过测试的平台和配置

我们的测试包括以下22种平台/配置。在某些情况下，由于缺乏对特定PHP版本的支持，我们不得不测试多个版本。单击下面的一个可直接跳至其测试说明和结果。数据以每秒请求数衡量。请求越多越好。

WordPress 5.3
WordPress 5.3 + WooCommerce 3.8.1
WordPress 5.3 +简易数字下载2.9.20
Drupal 8.8.0
Joomla！ 3.9.13
Magento 2（CE）2.2.10 + 2.3.3
Grav CMS 1.6.19
十月CMS 1.0.458
Laravel 5.8.35 + 6.7.0
Symfony 4.4.2 + 5.0.1
CodeIgniter 3.1.11 + 4.0-rc.3
CakePHP 3.8.7 + 4.0.0
PyroCMS 3.7
Pagekit 1.0.17
螺栓CMS 3.7.0
Craft CMS 3.4.0-beta.4
ExpressionEngine 5.3.0

由于每个平台上的演示内容可能会发生很大变化，因此，我们决定测试新的准系统安装的原始性能。

WordPress 5.3

当然，我们测试的第一个平台是我们最喜欢的平台之一：WordPress（我们每天都会生活和呼吸CMS，这可能会有点偏bias）。 WordPress的核心是开源软件，您可以使用它来创建漂亮的网站，博客或应用。实际上，WordPress占Internet上所有网站的35.2％。是的-您访问的网站中，有超过三分之一是由WordPress提供支持的。

我们从WordPress 5.3开始，它是撰写本文时的最新版本。我们使用了新的Twenty Twenty主题，并与15个并发用户对网站进行了基准测试一分钟。

经过测试的网址：/ hello-world /
注意：该页面包含1条注释，一个带有几个菜单的导航栏。侧边栏包含一些默认的WordPress小部件。
Docker镜像源自https://hub.docker.com/_/wordpress/。

WordPress 5.3 PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

WordPress 5.3 PHP 5.6基准测试：97.71 req / sec
WordPress 5.3 PHP 7.0基准测试结果：256.81 req / sec
WordPress 5.3 PHP 7.1基准测试结果：256.99 req / sec
WordPress 5.3 PHP 7.2基准测试结果：273.07 req / sec
WordPress 5.3 PHP 7.3基准测试结果：305.59 req / sec
WordPress 5.3 PHP 7.4基准测试结果：313.42 req / sec

PHP 7.4是赢家，被证明比PHP 7.3快一点。而且，如果将PHP 7.4与PHP 5.6进行比较，它每秒可处理的请求（事务）数量是3倍以上！

WordPress 5.3 + WooCommerce 3.5.2

WooCommerce是为WordPress构建的完全可自定义的开源电子商务平台。到目前为止，它也是WordPress社区中最受欢迎的电子商务解决方案之一，目前为互联网上所有电子商务网站中的14％以上的网站提供支持。

在下一个测试中，我们将WordPress和WooCommerce一起安装。我们利用了免费的Storefront eCommerce主题（2.5.3）。

经测试的网址：/ product / woo-ninja /
注意：此页面包含3个相关产品，1个产品评论/评论，“您可能也喜欢”部分中的1个产品以及下一个和上一个分页中的产品。
Docker镜像源自https://hub.docker.com/_/wordpress/。

WordPress 5.3 + WooCommerce PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

WordPress 5.3 + WooCommerce 3.8.1 PHP 5.6基准测试结果：49.29 req / sec
WordPress 5.3 + WooCommerce 3.8.1 PHP 7.0基准测试结果：117.35 req / sec
WordPress 5.3 + WooCommerce 3.8.1 PHP 7.1基准测试结果：117.52 req / sec
WordPress 5.3 + WooCommerce 3.8.1 PHP 7.2基准测试结果：125.85 req / sec
WordPress 5.3 + WooCommerce 3.8.1 PHP 7.3基准测试结果：141.68 req / sec
WordPress 5.3 + WooCommerce 3.8.1 PHP 7.4基准测试结果：146.07 req / sec?

在运行WooCommerce时，PHP 7.4远远超过了PHP 7.3。

WordPress 5.3 +简易数字下载2.9.20

由Pippin Williamson创建的Easy Digital Downloads（EDD）是一个免费的WordPress电子商务插件，主要致力于帮助创作者和开发者销售数字产品。

在了解了WooCommerce的表现之后，我们随后将WordPress和Easy Digital Downloads一起安装了。我们利用了免费的主题主题（1.0.7）。

经测试的网址：/ downloads / side-hustle /
注意：该页面是EDD的单一产品，包含图像，几段文字行，购买按钮和类别链接。
Docker镜像源自https://hub.docker.com/_/wordpress/。

WordPress 5.3 + Easy Digital下载PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

WordPress 5.3 + EDD 2.9.20 PHP 5.6基准测试结果：136.73 req / sec
WordPress 5.3 + EDD 2.9.20 PHP 7.0基准测试结果：323.84 req / sec
WordPress 5.3 + EDD 2.9.20 PHP 7.1基准测试结果：326.32 req / sec
WordPress 5.3 + EDD 2.9.20 PHP 7.2基准测试结果：346.51 req / sec
WordPress 5.3 + EDD 2.9.20 PHP 7.3基准测试结果：390.85 req / sec
WordPress 5.3 + EDD 2.9.20 PHP 7.4基准测试结果：400.78 req / sec

PHP 7.4也是使用WordPress和Easy Digital Downloads最快的。

当涉及WordPress，WooCommerce和Easy Digital Downloads时，事实证明，PHP 7.4的整体速度略快！

Drupal 8.8.0

Drupal是一个开源CMS，因其模块化系统和强大的开发人员社区而广受欢迎。它最初于2000年推出，根据W3Techs的说法，该网站为内容管理系统市场中3.0％的份额提供了1.7％的支持。

对于Drupal基准，我们使用了免费的Umami默认主题（8.8.0）。

经过测试的网址：/ zh-CN / articles / dairy-free-and-delicious-milk-chocolate
注意：Drupal安装有内置的虚拟数据“ Umami Food Magazine（实验性）”。
Drupal 8.8不再支持PHP 5.6，并且不兼容PHP 7.4（https://www.drupal.org/project/drupal/issues/3086374）。
Docker镜像源自https://hub.docker.com/_/drupal/。

Drupal PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

Drupal 8.8.0 PHP 5.6基准测试结果：不支持
Drupal 8.8.0 PHP 7.0基准测试结果：18.47请求/秒
Drupal 8.8.0 PHP 7.1基准测试结果：18.81req / sec
Drupal 8.8.0 PHP 7.2基准测试结果：19.38请求/秒
Drupal 8.8.0 PHP 7.3基准测试结果：21.56 req / sec?
Drupal 8.8.0 PHP 7.4基准测试结果：不支持

当运行Drupal时，PHP 7.3在性能上有了很大的提高。与以前的PHP版本相比，这是一个更大的飞跃。

Joomla！ 3.9.13

Joomla！是用于发布Web内容的免费开源CMS，最初于2005年8月17日发布。它基于模型-视图-控制器Web应用程序框架构建，根据W3Techs的统计，互联网上所有网站的使用率为2.6％。

对于Joomla！基准，我们利用了Joomla！中包含的免费Protostar（1.0）模板！ 3.x发行包。

经过测试的网址：/（首页）
注意：Joomla！随“默认英语（GB）示例数据”一起安装。它在主页上提供了基本的虚拟内容。主页在侧栏上包含几段内容，一个搜索输入表单以及一些基本小部件。
Docker镜像源自https://hub.docker.com/_/joomla/。

Joomla！ PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

Joomla！ 3.9.13 PHP 5.6基准测试结果：48.40 req / sec
Joomla！ 3.9.13 PHP 7.0基准测试结果：67.80 req / sec
Joomla！ 3.9.13 PHP 7.1基准测试结果：67.37 req / sec
Joomla！ 3.9.13 PHP 7.2基准测试结果：68.53 req / sec
Joomla！ 3.9.13 PHP 7.3基准测试结果：71.63 req / sec
Joomla！ 3.9.13 PHP 7.4基准测试结果：76.31 req / sec?

在Joomla上！我们可以看到整体表现有些差。从PHP 5.6到7.0+的性能有了巨大的提高。并快速前进到PHP 7.4，无疑是Joomla的赢家！

Magento 2（CE）2.2.10 + 2.3.3

Magento是使用PHP编写的流行的开源电子商务平台，于2008年3月31日发布。截至2018年，Magento现在是Adobe公司。据W3Techs称，它为互联网上所有网站的0.8％提供支持。

对于Magento 2基准，我们使用了免费的Luma主题。由于2.2.10仅支持PHP 7.2，所以我们使用了两个版本。对于其他测试，我们使用2.3.3。

经测试的URL：/lifelong-fitness-iv.html
注意：禁用了生成静态HTML页面的页面缓存。经测试的URL是单个产品。它包含一个图像产品，一个导航栏，面包屑导航，并且没有评论。
Magento 2不再支持PHP 5.6，并且与PHP 7.4不兼容。
http://pubfiles.nexcess.net/magento/ce-packages/

Magento 2 PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

Magento 2（CE）2.2.10 PHP 5.7基准测试结果：不支持
Magento 2（CE）2.2.10 PHP 7.0基准测试结果：28.33 req / sec
Magento 2（CE）2.2.10 PHP 7.1基准测试结果：28.51 req / sec
Magento 2（CE）2.2.10 PHP 7.2基准测试结果：29.58 req / sec
Magento 2（CE）2.2.10 PHP 7.3基准测试结果：不支持
Magento 2（CE）2.2.10 PHP 7.4基准测试结果：不支持
Magento 2（CE）2.3.0 PHP 5.6基准测试结果：不支持
Magento 2（CE）2.3.0 PHP 7.0基准测试结果：不支持
Magento 2（CE）2.3.0 PHP 7.1基准测试结果：25.33 req / sec
Magento 2（CE）2.3.0 PHP 7.2基准测试结果：27.01 req / sec
Magento 2（CE）2.3.0 PHP 7.3基准测试结果：29.97 req / sec?
Magento 2（CE）2.3.0 PHP 7.4基准测试结果：不支持

Magento 2 PHP基准测试的差异不大。但是好消息是，Magento的最新版本以及受支持的最新PHP版本（7.3）是最快的。

Grav CMS 1.6.19

Grav是易于使用但功能强大的开源CMS，不需要数据库。有时也称为平面文件CMS。

对于Grav CMS基准，我们使用了免费的Clean Blog框架包。

经测试的URL：/ home / the-urban-jungle
Grav CMS不再支持PHP 5.6和7.0。
注意：内容是一个简单的单栏博客文章，没有侧边栏。 Core GravCMS缓存已禁用。

Grav CMS PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

Grav CMS 1.6.19 PHP 5.6基准测试结果：不支持
Grav CMS 1.6.19 PHP 7.0基准测试结果：不支持
Grav CMS 1.6.19 PHP 7.1基准测试结果：62.25 req / sec
Grav CMS 1.6.19 PHP 7.2基准测试结果：64.69 req / sec
Grav CMS 1.6.19 PHP 7.3基准测试结果：69.07 req / sec
Grav CMS 1.6.19 PHP 7.4基准测试结果：75.04 req / sec

通过Grav CMS，我们可以看到最新版本的PHP 7.4是冠军。

也很高兴看到这些较小的内容管理系统不再支持旧版本的PHP。尽管这是不那么大的一个优点。不幸的是，当涉及到具有很大市场份额的WordPress和其他平台时，由于兼容性问题，事情进展缓慢。

十月CMS 1.0.458

October CMS是基于Laravel PHP框架的免费，开源，自托管和模块化CMS平台。它最初于2014年5月15日发布。

对于十月CMS基准，我们使用了免费的Clean Blog主题。

经测试的URL：/ blog / post / first-blog-post
October CMS不再支持PHP 5.6，并且不兼容PHP 7.4（https://github.com/octobercms/october/issues/4381）。

十月CMS PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

十月CMS 1.0.458 PHP 5.6基准测试结果：不支持
10月CMS 1.0.458 PHP 7.0基准测试结果：44.83 req / sec
10月CMS 1.0.458 PHP 7.1基准测试结果：45.21 req / sec
10月CMS 1.0.458 PHP 7.2基准测试结果：46.71 req / sec
十月CMS 1.0.458 PHP 7.3基准测试结果：49.26 req / sec?
十月CMS 1.0.458 PHP 7.4基准测试结果：不支持

PHP 7.3是赢家，即使只是一点点。 PHP 7.4一旦受支持，也很有可能会进行改进。

Laravel 5.8.35 + 6.7.0

Laravel是一个非常流行的开源PHP框架，用于开发Web应用程序。它是由泰勒·奥特威尔（Taylor Otwell）创建的，于2011年6月发布。

对于Laravel基准测试，我们使用了普通的HTML主题。

经过测试的网址：/（首页）
该帖子包含标题，作者姓名和主要内容。该数据库包含1个表“ posts”。该表包含6列“ post_title”，“ post_content”，“ post_author”，“ created_at”和“ updated_at”。
经测试的URL连接到数据库，并在表上显示所有帖子。此外，Laravel应用程序包含1条路线和1个控制器来显示这些内容。
Laravel 5.8.35不再支持PHP 5.6或PHP 7.0。 Laravel 6.7.0不再支持PHP 5.6、7.0或7.1。

Laravel PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

Laravel 5.8.35 PHP 5.6基准测试结果：不支持
Laravel 5.8.35 PHP 7.0基准测试结果：不支持
Laravel 5.8.35 PHP 7.1基准测试结果：380.52 req / sec
Laravel 5.8.35 PHP 7.2基准测试结果：382.80 req / sec
Laravel 5.8.35 PHP 7.3基准测试结果：400.22 req / sec
Laravel 5.8.35 PHP 7.4基准测试结果：402.39 req / sec?
Laravel 6.7.0 PHP 5.6基准测试结果：不支持
Laravel 6.7.0 PHP 7.0基准测试结果：不支持
Laravel 6.7.0 PHP 7.1基准测试结果：不支持
Laravel 6.7.0 PHP 7.2基准测试结果：383.21 req / sec
Laravel 6.7.0 PHP 7.3基准测试结果：392.74 req / sec
Laravel 6.7.0 PHP 7.4基准测试结果：394.96 req / sec

在这两个版本上，PHP 7.4都是明显的赢家。但是，有趣的是，带有PHP 7.4的Laravel 5.8.35似乎比Laravel 6.7.0快。

Symfony 4.4.2 + 5.0.1

Symfony是一组可重用的PHP组件和一个PHP框架，用于构建Web应用程序，API，微服务和Web服务。它于2005年10月22日发布。

对于Symfony基准，我们将Symfony演示版与MySQL配合使用（默认为SQLite）。

经过测试的网址：/ en / blog / posts / hello-world
帖子包含标题，日期，作者姓名，2个标签和5条评论。
Symfony 4.4.2不再支持PHP 5.6或PHP 7.0。 Symfony 5.0.1不再支持PHP 5.6、7.0或7.1。

Symfony PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

Symfony 4.4.2 PHP 5.6基准测试结果：不支持
Symfony 4.4.2 PHP 7.0基准测试结果：不支持
Symfony 4.4.2 PHP 7.1基准测试结果：295.84 req / sec
Symfony 4.4.2 PHP 7.2基准测试结果：309.26 req / sec
Symfony 4.4.2 PHP 7.3基准测试结果：327.61 req / sec
Symfony 4.4.2 PHP 7.4基准测试结果：338.18 req / sec?
Symfony 5.0.1 PHP 5.6基准测试结果：不支持
Symfony 5.0.1 PHP 7.0基准测试结果：不支持
Symfony 5.0.1 PHP 7.1基准测试结果：不支持
Symfony 5.0.1 PHP 7.2基准测试结果：229.09 req / sec
Symfony 5.0.1 PHP 7.3基准测试结果：239.96 req / sec
Symfony 5.0.1 PHP 7.4基准测试结果：252.22 req / sec

我们可以看到Symfony版本4.4.2和PHP 7.4是最快的。

CodeIgniter 3.1.11 + 4.0-rc.3

CodeIgniter是一个功能强大的PHP框架，占地面积很小，是为需要简单优雅的工具箱来创建功能齐全的Web应用程序的开发人员而构建的。

经过测试的网址：/（首页）
注意：帖子包含标题，作者姓名和主要内容。该数据库包含1个表“ posts”。该表包含6列“ post_title”，“ post_content”，“ post_author”，“ created_at”和“ updated_at”。
经测试的URL连接到数据库，并在表上显示所有帖子。此外，CodeIgniter应用程序包含1个路由和1个控制器来显示这些内容。
CodeIgniter 4.0-rc.3不支持PHP 5.6、7.0或7.1。

CodeIgniter PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

CodeIgniter 3.1.11 PHP 5.6基准测试结果：292.81 req / sec
CodeIgniter 3.1.11 PHP 7.0基准测试结果：358.40 req / sec
CodeIgniter 3.1.11 PHP 7.1基准测试结果：369.93 req / sec
CodeIgniter 3.1.11 PHP 7.2基准测试结果：383.24 req / sec
CodeIgniter 3.1.11 PHP 7.3基准测试结果：392.28 req / sec
CodeIgniter 3.1.11 PHP 7.4基准测试结果：394.96 req / sec?
CodeIgniter 4.0-rc.3 PHP 5.6基准测试结果：不支持
CodeIgniter 4.0-rc.3 PHP 7.0基准测试结果：不支持
CodeIgniter 4.0-rc.3 PHP 7.1基准测试结果：不支持
CodeIgniter 4.0-rc.3 PHP 7.2基准测试结果：319.68 req / sec
CodeIgniter 4.0-rc.3 PHP 7.3基准测试结果：322.90 req / sec
CodeIgniter 4.0-rc.3 PHP 7.4基准测试结果：333.08 req / sec

与Laravel和Symfony一样，运行CodeIgniter时PHP 7.4是最快的。有趣的是CodeIgniter 3.1.11的速度明显快于4.0-rc.3。但是，请记住，它是一个候选发布版本。

CakePHP 3.8.7 + 4.0.0

CakePHP是一个开放源代码的Web快速开发框架，它使构建Web应用程序更简单，更快并且需要更少的代码。它于2005年4月发布。

经过测试的网址：/（首页）
注意：帖子包含标题，作者姓名和主要内容。该数据库包含1个表“ posts”。该表包含6列“ post_title”，“ post_content”，“ post_author”，“ created_at”和“ updated_at”。
经测试的URL连接到数据库，并在表上显示所有帖子。此外，CodeIgniter应用程序包含1个路由和1个控制器来显示这些内容。
CakePHP 4.0.0不支持PHP 5.6、7.0或7.1。

CakePHP基准

嵌入您的网站：

图src：金斯塔

基准结果

CakePHP 3.8.7 PHP 5.6基准测试结果：134.09 req / sec
CakePHP 3.8.7 PHP 7.0基准测试结果：254.58 req / sec
CakePHP 3.8.7 PHP 7.1基准测试结果：267.29 req / sec
CakePHP 3.8.7 PHP 7.2基准测试结果：270.94 req / sec
CakePHP 3.8.7 PHP 7.3基准测试结果：290.25 req / sec
CakePHP 3.8.7 PHP 7.4基准测试结果：294.06 req / sec?
CakePHP 4.0.0 PHP 5.6基准测试结果：不支持
CakePHP 4.0.0 PHP 7.0基准测试结果：不支持
CakePHP 4.0.0 PHP 7.1基准测试结果：不支持
CakePHP 4.0.0 PHP 7.2基准测试结果：245.49 req / sec
CakePHP 4.0.0 PHP 7.3基准测试结果：260.84 req / sec
CakePHP 4.0.0 PHP 7.4基准测试结果：259.58 req / sec

对于CakePHP，运行PHP 7.4的3.8.7版本是赢家。

PyroCMS 3.7

PyroCMS是一个开源软件，从本质上讲是Laravel的扩展，它使您可以更快地在框架上构建网站和应用程序。

对于PyroCMS基准测试，我们使用了免费的入门主题。

经过测试的网址：/ posts / welcome-to-pyrocms
PyroCMS 3.7不支持PHP 5.6或7.0。
注意：在PHP 7.4上运行时，我们遇到了错误。很可能是因为尚不支持。因此，我们无法将其纳入基准测试。

PyroCMS PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

PyroCMS 3.5.3 PHP 5.6基准测试结果：不支持
PyroCMS 3.5.3 PHP 7.0基准测试结果：不支持
PyroCMS 3.5.3 PHP 7.1基准测试结果：91.45 req / sec
PyroCMS 3.5.3 PHP 7.2基准测试结果：94.77 req / sec
PyroCMS 3.5.3 PHP 7.3基准测试结果：103.35 req / sec
PyroCMS 3.5.3 PHP 7.4基准测试结果：不支持

由于PyroCMS尚未使用PHP 7.4，因此PHP 7.3在这里赢得了少量测试。

Pagekit 1.0.17

Pagekit是由YOOtheme创建的开源模块化，轻量级CMS。它为您提供了创建漂亮网站的工具。它于2016年春季发布。

pagekit“ width =” 310“ height =” 79“ srcset =” https://kinsta.com/wp-content/uploads/2018/02/pagekit.png 750w，https://kinsta.com/wp-content/ uploads / 2018/02 / pagekit-300x76.png 300w，https：//kinsta.com/wp-content/uploads/2018/02/pagekit-610x155.png 610w“ data-lazy-sizes =”（最大宽度： 310px）100vw，310px“ src =” https://kinsta.com/wp-content/uploads/2018/02/pagekit.png“></p>
<p>对于Pagekit基准测试，我们使用了免费的One主题（默认Pagekit主题）。</p>
<ul>
<li>经过测试的网址：/ blog / 1
</li>
</ul>
<p><img decoding=

Pagekit PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

Pagekit 1.0.17 PHP 5.6基准测试结果：249.48 req / sec
Pagekit 1.0.17 PHP 7.0基准测试结果：401.77 req / sec
Pagekit 1.0.17 PHP 7.1基准测试结果：406.99 req / sec
Pagekit 1.0.17 PHP 7.2基准测试结果：419.56 req / sec
Pagekit 1.0.17 PHP 7.3基准测试结果：431.21 req / sec
Pagekit 1.0.17 PHP 7.4基准测试结果：438.39 req / sec

使用Pagekit进行测试时，PHP 7.4赢得了金牌。

螺栓CMS 3.7.0

Bolt CMS，即Bolt，是一种开源内容管理工具，力求尽可能简单明了。它基于Silex和Symfony组件，使用Twig和SQLite，MySQL或PostgreSQL。

对于Bolt CMS基准测试，我们使用了免费的Bolt Base 2018主题。

经过测试的网址：/ entry / hello-world
注意：使用内置虚拟内容生成器生成的内容。

Bolt CMS PHP基准测试

嵌入您的网站：

图src：金斯塔

基准结果

Bolt CMS 3.7.0 PHP 5.6基准测试结果：50.91 req / sec
Bolt CMS 3.7.0 PHP 7.0基准测试结果：132.49 req / sec
Bolt CMS 3.7.0 PHP 7.1基准测试结果：134.55 req / sec
Bolt CMS 3.7.0 PHP 7.2基准测试结果：139.02 req / sec
Bolt CMS 3.7.0 PHP 7.3基准测试结果：147.03 req / sec
Bolt CMS 3.7.0 PHP 7.4基准测试结果：162.77 req / sec

当使用Bolt CMS进行测试时，PHP 7.4赢得了金牌。看到自PHP 5.6以来的性能改进也令人惊奇。

Craft CMS 3.4.0-beta.4

Craft CMS是面向开发人员，设计师和Web专业人员的重点内容管理系统，融合了灵活性，强大功能和客户易用性。

经过测试的网址：/ news / barrel-aged-digital-natives
Craft CMS不支持PHP 5.6。
使用https://github.com/craftcms/demo测试了演示应用

Craft CMS PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

Craft CMS 3.4.0-beta.4 PHP 5.6基准测试结果：不支持
Craft CMS 3.4.0-beta.4 PHP 7.0基准测试结果：140.81 req / sec
Craft CMS 3.4.0-beta.4 PHP 7.1基准测试结果：145.75 req / sec
Craft CMS 3.4.0-beta.4 PHP 7.2基准测试结果：151.15 req / sec
Craft CMS 3.4.0-beta.4 PHP 7.3基准测试结果：163.95 req / sec
Craft CMS 3.4.0-beta.4 PHP 7.4基准测试结果：169.11 req / sec

PHP 7.4在使用Craft CMS进行测试时获得了金牌。

ExpressionEngine 5.3.0

ExpressionEngine是一个灵活的，功能丰富的内容管理平台，它使世界各地成千上万的个人和组织可以轻松地管理其网站。

对于ExpressionEngine基准，我们使用了默认主题。

经测试的URL：/ blog / entry / super-old-entry
ExpressionEngine不支持PHP 5.6。
注意：页面包含带有3个小部件（搜索，类别列表和RSS feed链接）的侧栏。页面还包含面包屑导航。

ExpressionEngine PHP基准

嵌入您的网站：

图src：金斯塔

基准结果

ExpressionEngine 5.3.0 PHP 5.6基准测试结果：不支持
ExpressionEngine 5.3.0 PHP 7.0基准测试结果：101.32 req / sec
ExpressionEngine 5.3.0 PHP 7.1基准测试结果：103.54 req / sec
ExpressionEngine 5.3.0 PHP 7.2基准测试结果：107.79 req / sec
ExpressionEngine 5.3.0 PHP 7.3基准测试结果：108.35 req / sec
ExpressionEngine 5.3.0 PHP 7.4基准测试结果：110.56 req / sec

用ExpressionEngine进行测试时，PHP 7.4赢得了金牌。

在Kinsta更新到PHP 7.4

如果上述结果无法说服您，我们不确定会怎样！只是一个善意的提醒。如果您是Kinsta客户端，则可以使用PHP 7.2、7.3和7.4。如果您希望获得性能方面的改进，则只需在MyKinsta仪表板中单击即可轻松更改为较新版本。

更改为PHP 7.4

如果您担心它与第三方插件不兼容（可能会发生），这正是我们拥有临时站点的原因。 ?您可以进行测试，而不必担心破坏生产现场。

从基准结果中总结

从上面的测试中可以清楚地看到，在所有平台的性能方面，PHP 7.4处于领先地位。

我们在6个不同的PHP版本上测试了22个平台/配置的性能，而#PHP 7.4在17/17（5 N / A）上大获全胜！ ?

点击鸣叫

在上面测试的22种配置中，PHP 7.4是17种中最快的引擎。一个原因并非不是赢家，仅仅是因为Drupal，Magento 2，十月CMS，PyroCMS尚未完全支持PHP 7.4或存在兼容性问题。
就WordPress而言，PHP 7.4是所有测试中最快的（WordPress站点有5.3，WooCommerce和Easy Digital Downloads）。
在许多基准测试结果中，您可以轻松地发现发布的每个新版本的PHP都可以提高性能。这就是为什么测试您的网站，插件等并坚持定期的升级计划如此重要的原因。您的访客和客户将感谢您，因为他们期望速度！
如果您的托管服务提供商不提供更新版本的PHP，那么也许您该考虑迁移了。
对于WordPress用户，除了升级到最新的PHP版本外，我们还收集了许多其他技术，可以帮助您进一步改善网站性能。请参阅我们的最终指南中有关如何加快WordPress网站速度的详细信息。

我们对PHP 7.4感到非常兴奋，希望您也是如此！我们很想听听您对基准测试的想法，甚至是您升级后的经验。将它们放在评论中。

1.5K分享

901
347
1个
93
0
1个
0
158

原文： https://wpjian.com/tips/2020010729805.html

Linux修改swap大小的方法

修改swap大小操作需要root权限，

cd /usr/

mkdir swap

cd swap

dd if=/dev/zero of=swapfile bs=4G count=4

这条命令从硬盘里分出一个 4×4G 大小的空间，挂在swapfile上。
1
2
3
4
5
6

mkswap swapfile

构建swap格式于/usr/swap/swapfile 上
1
2

swapon swapfile

1
以上操作在重启系统后swap空间将会失去swapfile ，将swapfile 加入到/etc/fstab
条目将可以使得系统在init进程中调用swapon -a 来自动挂载swapfile ，这样每次机器重启后swapfile
都处于有效的swap空间。

在/etc/fstab文件中加入下面这样一行：
/usr/swap/swapfile swap swap defaults 0 0
1
2
删除：

swapoff /user/swap/swapfile 停掉swap

rm -rf /user/swap/swapfile 删除

php 7.2 安装 mcrypt 扩展

Mcrypt 简介

Mcrypt 库提供了对多种块算法的支持，包括：DES，TripleDES，Blowfish （默认）， 3-WAY，SAFER-SK64，SAFER-SK128，TWOFISH，TEA，RC2 以及 GOST，并且支持 CBC，OFB，CFB 和 ECB 密码模式

环境：centos 7

yum 安装依赖包：

yum install libmcrypt libmcrypt-devel mcrypt mhash

在 php 官网下载 mcrypt 包，php 扩展官网

# wget http://pecl.php.net/get/mcrypt-1.0.1.tgz

# tar xf mcrypt-1.0.1.tgz

# cd mcrypt-1.0.1

编译安装 mcrypt

# /usr/local/php/bin/phpize

# ./configure –with-php-config=/usr/local/php/bin/php-config && make && make install

在php.ini加上扩展即可

extension=mcrypt.so

重启 php-fpm

/etc/init.d/php-fpm restart

MySQL5.6数据导入MySQL5.7报错：ERROR 1031 (HY000)

一、故障现象

今天将一个在MySQL5.7上的数据导入到MySQL5.6里面去，默认存储引擎都是InnoDB，导入报错如下：

[root@oratest52 data]# mysql -uroot -p123456 < /data/127.sql
ERROR 1031 (HY000) at line 598885: Table storage engine for 't_config_dbconnects' doesn't have this option

报错提示598885行有问题，t_config_dbconnects表的存储引擎不支持这个选项。由于备份文件较大(50G)，不可能用vi打开去看，用sed文件查看该表的建表sql如下：

[root@oratest52 data]# sed -n '598870,598899p' 127.sql
--
-- Current Database: `db_config`
--

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `db_config` /*!40100 DEFAULT CHARACTER SET utf8 */;

USE `db_config`;

--
-- Table structure for table `t_config_dbconnects`
--

DROP TABLE IF EXISTS `t_config_dbconnects`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `t_config_dbconnects` (
  `ID` smallint(6) unsigned NOT NULL AUTO_INCREMENT,
  `NAME` char(50) DEFAULT NULL,
  `HOST` char(50) NOT NULL DEFAULT '',
  `PORT` char(10) NOT NULL DEFAULT '',
  `USER` char(50) NOT NULL DEFAULT '',
  `PASSWORD` char(50) NOT NULL DEFAULT '',
  `CHARSET` char(30) DEFAULT NULL,
  `DBNAME` char(50) NOT NULL DEFAULT '',
  `ABOUT` char(200) DEFAULT NULL,
  `POSTTIME` datetime DEFAULT NULL,
  `LASTUSER` char(50) DEFAULT NULL,
  PRIMARY KEY (`ID`),  
  UNIQUE KEY `IDX_NAME` (`NAME`)
) ENGINE=InnoDB AUTO_INCREMENT=84 DEFAULT CHARSET=utf8 ROW_FORMAT=FIXED;

可以看到最后一行中有ROW_FORMAT=FIXED

二、初步分析

发现报错的表的ROW_FORMAT格式是FIXED，并不是我们熟悉的Dynamic。查看资料和官方文档发现不同版本或者不同源的MySQL对于行记录格式的处理方式不一样，解决上述问题就先要了解row_format的改进历程，这里简单介绍下MyISAM和InnoDB两种存储引擎对于row_format格式的处理。

2.1MyISAM存储引擎

MyISAM有3种行存储格式：fixed/dynamic/compressed

fixed：为默认格式，只有当表不包含变长字段(varchar/varbinary/blob/text)时使用，该每行都是固定的，所以很容易获取行在页上的具体位置，存取效率比较高，但是占用磁盘空间较多
dynamic：每行都有一个行头部，包含bitmap，用以记录那些列为空(NULL列不算为空)
compressed只能通过myisampack创建且为只读

2.2InnoDB存储引擎

Innodb plugin新引入Barracuda，其包含compressed/dynamic两种行格式，而之前的compact/redundant统属于antelope；目前可选值为Antelope和Barracuda，低版本默认为Antelope，高版本默认为Barracuda。
了解这两种存储引擎如上两种row_format格式后，就能明白对一张MyISAM表且row_format为fixed格式的表更改存储殷勤为InnoDB肯定是不行的，因为InnoDB的row_format不支持fixed格式。所以可以先备份要更改引擎的表数据，然后将表的row_format更改为存储引擎都能识别的row_format，再进行引擎的变更。

mysql> alter table t_config_dbconnects ROW_FORMAT = default;
Query OK, 0 rows affected (0.15 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table t_config_dbconnects engine = innodb;
Query OK, 0 rows affected (2.67 sec)
Records: 0  Duplicates: 0  Warnings: 0

DNS压力测试工具dnsperf

1、dnsperf简介

DNSPerf（DNS Performance）来自Prospect One公司，刚好最近研究 DNS 又想起这项服务。DNSPerf 从全世界超过两百个城市节点来检测各个 DNS 速度、反应时间及上线率（Uptime），除此之外，DNSPerf 还有针对一般使用者会用到的开放式 DNS 解析服务（Public DNS）进行监测记录，比较令我感到意外的是解析速度方面OpenDNS居然还比Google DNS来得更快！有兴趣的朋友可以到 DNSPerf 看看测试结果，对于读者来说还是蛮有参考价值的。dnsperf目前的实现是单进程模式，通过epoll非阻塞地处理网络事件。

2、安装程序

 [root@docker-03 ~]# yum install dnsperf

3、参数详解

 ## Dnsperf 支持下面的这些命令行参数:
 -s    用来指定DNS服务器的IP地址，默认值是127.0.0.1
 -p    用来指定DNS服务器的端口，默认值是53
 -d    用来指定DNS消息的内容文件，该文件中包含要探测的域名和资源记录类型，见下文
 -t    用来指定每个请求的超时时间，默认值是3000ms
 -Q    用来指定本次压测的最大请求数，默认值是1000
 -c    用来指定并发探测数，默认值是100. dnsperf会从-d指定的文件中随机选取100个座位探测域名来发送DNS请求
 -l    用来指定本次压测的时间，默认值是无穷大
 -e    本选项通过EDNS0，在OPT资源记录中运用edns-client-subnet来指定真实的client ip
 -i    用来指定前后探测的时间间隔，因为dnsperf是一个压测工具，所以本选项目前还不支持
 -P    指定用哪个传输层协议发送DNS请求，udp或者tcp。默认值是udp
 -f    指定用什么地址类型发送DNS请求，inet或者inet6。默认值是inet
 -v    除了标准的输出外，还输出每个相应码的个数
 -h    打印帮助

4、数据文件示例

-d选项指定数据文件名，数据文件示例如下，测试的次数和域名拷贝次数要一样：

 # This is a comment and is ommited
 # The columns after column 2 will be ommited if one line contains more than 3 colums.
 www.app1.com A

数据文件中以“#”开头的行被认为是注释行，会被dnsperf忽略。

其中有效数据由两列组成，第一列是查询域名，第二列是查询的资源类型，dnsperf支持的资源类型如下：

A，NS，MD，MF，CNAME，SOA，MB，MG，MR，NULL，WKS，PTR，HINFO，MINFO，MX，TXT，AAAA，SRV，NAPTR，A6，ASFR，MAILB，MAILA，ANY

5、性能评测指标

 [root@RedHat_test opt]# dnsperf -c 1000 -d testfile -s 172.17.0.98
 DNS Performance Testing Tool
 Version 2.3.2
 
 [Status] Command line: dnsperf -c1000-dtestfile -s172.17.0.98
 [Status] Sending queries (to 172.17.0.98)
 [Status] Started at: Wed Jan 1515:34:50 2020
 [Status] Stopping after 1run through file
 [Status] Testing complete (end of file)
 
 Statistics:
 
 Queries sent:         325336
 Queries completed:    325336(100.00%)
 Queries lost:         0(0.00%)
 
 Response codes:       NOERROR 325336(100.00%)
 Average packet size: request 29, response 75
 Run time (s):         3.624032
 Queries per second:   89771.834244
 
 Average Latency (s):  0.000990 (min 0.000335, max 0.016325)
 Latency StdDev (s):   0.000441

1、queryperf简介

在bind中，有一款自带的压力测试软件，queryperf。使用这款软件可以对DNS服务器作请求测试，并且使用方法简单，我们可以使用queryperf测试多次，取一个平均值，这样就算结果不准确，也不会和实际情况相差太大。

2、安装程序

 [root@docker-03 ~]# cd /usr/local/src
 [root@docker-03 src]# wget http://ftp.isc.org/isc/bind9/9.12.1/bind-9.12.1.tar.gz
 [root@docker-03 src]# tar -zxvf bind-9.12.1.tar.gz
 [root@docker-03 queryperf]# cd /usr/local/src/bind-9.12.1/contrib/queryperf
 [root@docker-03 queryperf]# ./configure
 [root@docker-03 queryperf]# make
 [root@docker-03 queryperf]# cp queryperf /usr/bin

3、参数详解

 ## queryperf [-d datafile] [-s server_addr] [-p port] [-q num_queries]
 -d: 后面接上一个文件，文件的内容是用户对DNS的请求，一行为一条请求，所以为了测试，我们可以在里面写上几千几万条。
 -s: DNS服务器地址
 -p: DNS服务器端口
 -q: 指定查询的输出的最大数量

4、sh批量生产记录

 [root@docker-03 queryperf]# cat gen_record.sh 
 #!/bin/sh
 #a_record="ns2.paiconf.com"
 
 a_record=$1
 num=$2
 file_path=$3
 
 if[ ${a_record}-a${num}-a${file_path}]; then
 var=1
 while[ $var-le${num}]
 do
 echo"${a_record}A ">> ${file_path}
 var=$(($var+ 1 ))
 done
 else
    echo"use: ./sh [a_record] [num] [file_path]"
 fi

5、使用方法

 [root@docker-03 queryperf]# chmod -R 777 gen_record.sh 
 [root@docker-03 queryperf]# ./gen_record.sh www.baidu.com 10000 dnstest.txt
 [root@docker-03 queryperf]# queryperf -d dnstest.txt -s 172.17.0.98
 
 DNS Query Performance Testing Tool
 Version: $Id: queryperf.c,v 1.12 2007/09/05 07:36:04 marka Exp $
 
 [Status] Processing input data
 [Status] Sending queries (beginning with 172.17.0.98)
 [Status] Testing complete
 
 Statistics:
 
 Parse input file:     once
 Ended due to:         reaching end of file
 
 Queries sent:         10000queries
 Queries completed:    10000queries
 Queries lost:         0queries
 Queries delayed(?):   0queries
 
 RTT max:         0.011268 sec
 RTT min:              0.000267 sec
 RTT average:          0.000417 sec
 RTT std deviation:    0.000466 sec
 RTT out of range:     0queries
 
 Percentage completed: 100.00%
 Percentage lost:        0.00%
 
 Started at:           Wed Jan 1518:31:55 2020
 Finished at:         Wed Jan 1518:31:56 2020
 Ran for:              0.226052 seconds
 
 Queries per second:   44237.609046 qps