分类目录归档:cdn

fredzeng与你一起对cdn,cdn加速,cdn是什么,免费cdn,cdn公司,cdn厂商,cdn技术学习相关知识及探讨!

部署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 ***

+————————————————————————————————————————+
| @@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)

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托管的网站的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 CMS

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

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

WordPress 5.3 PHP基准测试

WordPress

嵌入您的网站:

图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%以上的网站提供支持。

WooCommerce

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

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

WordPress 5.3 + WooCommerce PHP基准测试

WordPress

嵌入您的网站:

图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基准

WordPress 5.3 + Easy Digital下载PHP基准

WordPress

嵌入您的网站:

图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

对于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基准

Drupal PHP基准

Joomla!

嵌入您的网站:

图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!基准,我们利用了Joomla!中包含的免费Protostar(1.0)模板! 3.x发行包。

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

Joomla! PHP基准

Joomla!

嵌入您的网站:

图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

对于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基准测试

Magento 2 PHP基准测试

Magento

嵌入您的网站:

图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

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

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

Grav CMS PHP基准

Grav

嵌入您的网站:

图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

对于十月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基准测试

十月CMS PHP基准测试

October

嵌入您的网站:

图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徽标

对于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基准测试

Laravel PHP基准测试

Laravel

嵌入您的网站:

图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基准,我们将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基准

Symfony PHP基准

Symfony

嵌入您的网站:

图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应用程序的开发人员而构建的。

CodeIgniter徽标
  • 经过测试的网址:/(首页)
  • 注意:帖子包含标题,作者姓名和主要内容。该数据库包含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基准测试

CodeIgniter PHP基准测试

CodeIgniter

嵌入您的网站:

图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月发布。

CakePHP徽标
  • 经过测试的网址:/(首页)
  • 注意:帖子包含标题,作者姓名和主要内容。该数据库包含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基准

CakePHP基准

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的扩展,它使您可以更快地在框架上构建网站和应用程序。

高温CMS

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

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

PyroCMS PHP基准

PyroCMS

嵌入您的网站:

图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基准测试

Pagekit

嵌入您的网站:

图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。

螺栓CMS

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

  • 经过测试的网址:/ entry / hello-world
  • 注意:使用内置虚拟内容生成器生成的内容。
Bolt CMS PHP基准测试

Bolt CMS PHP基准测试

Bolt

嵌入您的网站:

图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专业人员的重点内容管理系统,融合了灵活性,强大功能和客户易用性。

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

Craft CMS PHP基准

Craft

嵌入您的网站:

图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基准

ExpressionEngine PHP基准

ExpressionEngine

嵌入您的网站:

图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

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

从基准结果中总结

从上面的测试中可以清楚地看到,在所有平台的性能方面,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

  1. fixed:为默认格式,只有当表不包含变长字段(varchar/varbinary/blob/text)时使用,该每行都是固定的,所以很容易获取行在页上的具体位置,存取效率比较高,但是占用磁盘空间较多
  2. dynamic:每行都有一个行头部,包含bitmap,用以记录那些列为空(NULL列不算为空)
  3. 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支持的资源类型如下:

ANSMDMFCNAMESOAMBMGMRNULLWKSPTRHINFOMINFOMXTXTAAAASRVNAPTRA6ASFRMAILBMAILAANY

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