常见开发语言统计及 Web开发性能统计网站
开发编程语言统计趋势
https://www.tiobe.com/tiobe-index/
常见 WEB 开发框架 性能对比 网站
https://www.techempower.com/benchmarks/
可以看到php相关的性能laravel最优雅的夺得性能倒数榜。
常见开发语言统计及 Web开发性能统计网站
可以看到php相关的性能laravel最优雅的夺得性能倒数榜。
分类目录归档：cdn
可以看到php相关的性能laravel最优雅的夺得性能倒数榜。
Nginx location 匹配顺序整理
Nginx环境
a. 查看当前系统cat /etc/redhat-release
[root@nginx /]# cat /etc/redhat-release
CentOS release 6.7 (Final)
[root@nginx /]#
b. 查看系统内核uname –r
[root@nginx /]# uname -r
2.6.32-573.el6.x86_64
[root@nginx /]#
c. 安装的Nginx版本,/appliation/nginx/sbin/nginx -V
[root@nginx sbin]# ./nginx -V
nginx version: nginx/1.6.2
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC)
TLS SNI support enabled
configure arguments: –user=nginx –group=nginx –prefix=/application/nginx1.6.2 –with-http_stub_status_module –with-http_ssl_module
[root@nginx sbin]#
location模块
Nginx location
location 指令的作用是根据用户请求的URI来执行不同的应用，URI就是根据用户请求到的网址URL进行匹配，匹配成功了进行相关的操作。
location语法
下面是官网的语法结构：
Syntax: location [ = | ~ | ~* | ^~ ] uri { … }
location @name { … }
Default: —
Context: server, location
官网解释翻译和理解
下面会结合官网原文进行解释，以下英文部分均从官网摘抄：
（翻译的不好勿喷）
Sets configuration depending on a request URI.
根据请求的URI进行配置
URI 变量是待匹配的请求字符串，
A location can either be defined by a prefix string, or by a regular expression.
Regular expressions are specified with the preceding “~*” modifier (for case-insensitive matching), or the “~” modifier (for case-sensitive matching)
一个location可以用prefix string(前缀字符串)定义，也可以通过regular expression（正则表达式来定义）
通俗的说也就是：我们可以通过使用不同的前缀，表达不同的含义，对于不同的前缀可以分为两大类：普通location和正则location
符号：”~”表示uri包含正则，并且区分大小写
符号：“~*”表示uri包含正则，但不区分大小写
注意：如果你的uri用正则，则你的正则前面必须添加~或者~*,之前我在这里存在误区，以为可以不加~或者~*
To find location matching a given request, nginx first checks locations defined using the prefix strings (prefix locations). Among them, the location with the longest matching prefix is selected and remembered. Then regular expressions are checked, in the order of their appearance in the configuration file. The search of regular expressions terminates on the first match, and the corresponding configuration is used. If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used.
Nginx服务器会首先会检查多个location中是否有普通的uri匹配，如果有多个匹配，会先记住匹配度最高的那个。然后再检查正则匹配，这里切记正则匹配是有顺序的，从上到下依次匹配，一旦匹配成功，则结束检查，并就会使用这个location块处理此请求。如果正则匹配全部失败，就会使用刚才记录普通uri匹配度最高的那个location块处理此请求。
If the longest matching prefix location has the “^~” modifier then regular expressions are not checked.
当普通匹配的最长前缀匹配有符号“^~”的时候，就不会在匹配正则
直接使用当前匹配的这个location块处理此请求
Also, using the “=” modifier it is possible to define an exact match of URI and location. If an exact match is found, the search terminates. For example, if a “/” request happens frequently, defining “location = /” will speed up the processing of these requests, as search terminates right after the first comparison. Such a location cannot obviously contain nested locations.
使用符号“=”修饰符可以定义一个精确匹配的URI和位置，如果找到了一个精确的匹配，则搜索终止，例如，如果一个”/”请求频繁发生，定义“location =/”将加快这些请求的处理，一旦精确匹配只有就结束，这样的location显然不能包含嵌套location
这里我们说一下location / {} 和location =/ {}的区别：
“location / {}”是普通的最大前缀匹配，任何的uri肯定是以“/”开头，所以location / {} 可以说是默认匹配，当其他都不匹配了，则匹配默认匹配
根据上述官网内容进行总结
a. ”=”用于普通uri前，要求精确匹配，如果匹配成功，则停止搜索并用当前location处理此请求
b. ”~” 表示uri包含正则，并且区分大小写
c. “~*”表示uri包含正则，但不区分大小写
d. ”^~”表示在普通uri前要求Nginx服务器找到普通uri匹配度最高的那个location后，立即处理此请求，并不再进行正则匹配
e. ”^~”和“=”都可以阻止继续匹配正则location两者的区别：“^~”依然遵守最大前缀原则，然后“=”是需要严格匹配
关于location网上的一些误解
location 的匹配顺序是“先匹配正则，再匹配普通”
这是一个错误的结论，从上面官网的文章中我们可以知道：
先匹配普通uri，然后记住匹配度最高的那个（官网原话：To find location matching a given request, nginx first checks locations defined using the prefix strings (prefix locations). Among them, the location with the longest matching prefix is selected and remembered.）然后匹配正则，如果正则匹配则结束查找，如果正则不匹配，则匹配之前普通匹配中匹配度最高的那个将执行该请求（官网原话：Then regular expressions are checked, in the order of their appearance in the configuration file. The search of regular expressions terminates on the first match, and the corresponding configuration is used. If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used.）
所以：location 的匹配顺序是“先匹配正则，再匹配普通” 这句话肯定是错误的，况且这里并没有包含”^~”和“=”
location 的执行逻辑跟 location 的编辑顺序无关。
这也是一种错误的理解，我们根据上述内容可以知道：
如果是普通uri 匹配，这个时候是没有顺序的，但是正则匹配则是有顺序的，是从上到下依次匹配，一旦有匹配成功，则停止后面的匹配。
那么顺序到底是怎么匹配呢？
我画了一个location匹配的逻辑图便于理解匹配的顺序规则
通过实验来验证出结果
对www.conf配置如下：
[root@nginx extra]# cat www.conf
server {
listen 80;
server_name www.zhaofan.com;
access_log logs/access_www.log;
root html/www;
location / {
return 401;
}
location = / {
return 402;
}
location /documents/ {
return 403;
}
location ^~ /images/ {
return 404;
}
location ~* \.(gif|jpg|jpeg)$ {
return 500;
}
}
[root@nginx extra]#
注意：
location ~* \.(gif|jpg|jpeg)$ {
return 500;
这个部分$前面不能有空格，否则会提示如下错误：
[root@nginx extra]# ../../sbin/nginx -s reload
nginx: [emerg] invalid location modifier “~*\.(gif|jpg|jpeg)” in /application/nginx1.6.2/conf/extra/www.conf:19
如果$后面没有空格，则会提示如下错误：
[root@nginx extra]# ../../sbin/nginx -s reload
nginx: [emerg] directive “location” has no opening “{” in /application/nginx1.6.2/conf/extra/www.conf:23
这些都是细节问题，一定要注意
实验一：登录nginx网站，我这里的直接打开：http://192.168.8.105/
可以看出这里是精确匹配
location = / {
return 402;
}
实验二：打开http://192.168.8.105/aaa/
这里可以看出因为都不匹配，所以最后匹配了location / {}
location / {
return 401;
}
实验三：打开http://192.168.8.105/1.gif
这里可以看出是匹配了正则
location ~* \.(gif|jpg|jpeg)$ {
return 500;
}
实验四：打开http://192.168.8.105/aaa/1.gif
这里依然是匹配正则
location ~* \.(gif|jpg|jpeg)$ {
return 500;
}
实验五：打开http://192.168.8.105/images/1.gif
location / {
return 401;
}
location = / {
return 402;
}
location /document/ {
return 403;
}
location ^~ /images/ {
return 404;
}
location ~* \.(gif|jpg|jpeg)$ {
return 500;
}
这里通过配置把实验三和实验四的对比就可以看出来因为普通匹配里有“^~”，并且匹配到了images,所以这个就是不进行正则匹配
location ^~ /images/ {
return 404;
}
实验六：“^~”遵守最大前缀原则
配置如下：
location / {
return 401;
}
location = / {
return 402;
}
location = /document/ {
return 403;
}
location ^~ /images/ {
return 404;
}
location /images/1/ {
return 501;
}
location ~* \.(gif|jpg|jpeg)$ {
return 500;
}
还是关注标红的地方，这个时候我们登陆：http://192.168.1.19/images/
结果如下：
从这里可以看出匹配了：
location ^~ /images/ {
return 404;
}
但是如果我们登陆：http://192.168.1.19/images/1/
结果如下;
这里匹配了：
location /images/1/ {
return 501;
}
从这里我们可以看出“^~”遵守最大匹配原则。
实验七：当最长匹配和精确匹配相同时
配置如下：
location / {
return 401;
}
location = / {
return 402;
}
location = /document/ {
return 403;
}
location ^~ /images/ {
return 404;
}
location /images/1/ {
return 501;
}
location = /images/1/ {
return 502;
}
location ~* \.(gif|jpg|jpeg)$ {
return 500;
}
登陆：http://192.168.1.19/images/1/
结果如下：
但是如果这个时候登陆：http://192.168.1.19/images/1/aaa/
结果如下：
从这里我们可以看出当精确匹配和最长匹配相同时，匹配的是精确匹配。
不在过多的做实验，根据上面的逻辑图应该可以解决碰到的问题了所有的努力都值得期许，每一份梦想都应该灌溉！
双显卡单屏幕电脑OBS获取chrome浏览器源为黑屏
在浏览器设置中关闭硬件加速，可以解决此问题。
但是在浏览网页，游戏需要渲染过多动画的时候会巨卡无比。
因为OBS只能捕获相同渲染方式的窗口
所以我们需要让Chrome浏览器默认使用OpenGL进行GPU加速
- 地址栏输入chrome://flags/#use-angle
- 选择OpenGL
- 重启浏览器 就大功告成了！
部署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进行音视频通话
成功后，会看到两个窗口，上面是本地的采集窗口，下面是视频通讯的多窗口
如果没有正常显示，可以通过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的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 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
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
删除：