Wordpress的臃肿在我没使用过这个系统的之前就意料到了,毕竟这是一个插件数量如此之多,多样性如此之丰富的一个系统, wordpress的主机速度调优我想也是许多草根的一块心病了~ 本文针对站长自己最近对本站的一些相关优化做一些分享,欢迎吐槽……

优化前

首先来看一下这未优化前本站抓狂的速度,下图是chrome的开发者工具,为了不受缓存影响, 已经启用了chrome的隐身模式,刷新三次,三次响应时间分别为2.61s 2.55s 2.13s,可以看到均在2.3s上下这个区间:QQ截图20151208222646

 

下图为Debug Queries插件统计的页面生成时间,可以看到生成页面用了1.8+s,而mysql根本就不是性能瓶颈:QQ截图20151208230736

 

可能你认为这速度还算可以了,毕竟还在黄金等待时间3s之内,如果说是共享主机这个响应时间应该不足为奇,不过如下图:QQ截图20151208223456QQ截图20151208223607

本站目前使用的是阿里云的第一代ECS,双核4G+2M带宽,数据库是阿里云RDS云数据库,另外本站资源除了部分插件的js和css文件,大部分图片资源和主要的js css都经过七牛的CDN,这样的配置,你说响应时间为何能变成这种程度呢? 一定是我打开的方式不对……

 

插件优化

首先怀疑的就是wp的插件,于是乎找到一个叫做 Plugin Performance Profiler 的插件性能检测 的插件,godaddy出品,检测结果如下:QQ截图20151208225440

 

表示比较无语,看到这个占比这么大片的这个插件。WP-SlimStat这个插件用wp的肯定不陌生,非常强大的一个访问量统计插件,没想到居然是它极大影响了页面响应速度。查看了一下站点首页源代码,发现这个插件对response给客户端的数据进行了极大的修改,比如对a标签等加上了各种自定义的属性,以进行各种访问反馈的回调统计,我估计着正是这个插件对响应给客户端的原始数据进行的各种正则匹配替换导致了页面响应如此之慢。

 

妥妥的禁用掉,重新进行速度测试,chrome三次响应,488ms 479ms 434ms:QQ截图20151208232128

 

Debug Queries显示页面生成时间:437msQQ截图20151208232351

 

插件运行占用时间从0.959s暴降到0.199sQQ截图20151208232658

 

PHP优化

基本上关闭这个插件之后站点的响应已经非常快了,不过Debug Queries中显示的php执行时间占比却貌似有些问题,为何请求中php脚本执行时间占比这么高,难道是阿里云mysql真的太给力了? 经过一番google,将问题锁定在php的Opocdes编译缓存上。

以java web来说,每一个servlet 每一个java类都会编译成中间.class文件部署到服务器上,然后当有请求进来的时候虚拟机直接进行对象创建接着处理请求(而不需要重新编译java文件,理所当然,毕竟java不是脚本语言),然而以java开发者这种理所当然的想法到php这来可就不那么理所当然了。php是一门脚本语言,同样的它也需要解析,编译。php代码最终编译成Opcodes,然后才执行。然而,在默认的情况下,php代码编译成Opcodes并且执行之后Opcodes就被丢弃了,而不是像java中的.class文件一样一次编译就可以无限使用,这导致php在处理每一个请求的时候都要先进行代码编译成Opcodes的这个步骤,然后才执行,极大的影响速度。

解决方案肯定是有的,我使用的是opcache。在php5.5+中集成了opcache模块,可以缓存php编译生成的Opcodes,开启方式如下:

  1. 编译PHP的时候带上以下参数编译opcache模块
    --enable-opcache
    
  2. php.ini文件中新增以下配置
    zend_extension=opcache.so
    ; 开启
    opcache.enable=1
    ; Determines if Zend OPCache is enabled for the CLI version of PHP
    opcache.enable_cli=1
    
    ; 使用内存大小.
    opcache.memory_consumption=512
    
    ; 缓冲池中字符串大小.
    opcache.interned_strings_buffer=8
    
    ; The maximum number of keys (scripts) in the OPcache hash table.
    ; Only numbers between 200 and 100000 are allowed.
    opcache.max_accelerated_files=10000
    
    ; 验证文件时时间戳
    opcache.validate_timestamps=1
    
    ; 文件验证间隔(秒)
    opcache.revalidate_freq=2
    
    ; 快速关闭
    opcache.fast_shutdown=1
    

 

php_info()可以看到opcache已经加载运行了:QQ截图20151209004208

 

再次进行测速,chrome三次响应:231ms 219ms 240ms:QQ截图20151209004421

 

Debug Queries显示的页面生成时间:172msQQ截图20151209004649

 

其他优化

  • 开启页面缓存。w3 total cache可以将整个生成的页面进行缓存,在一定的有效期内,客户端访问到的页面都是这个缓存页面,省去了php执行的过程,响应时间两位数毫秒级别,可见非常快。但是采用这种页面静态缓存的话页面上的内容如果变化了是无法及时更新的,必须手动刷新缓存或者等待页面缓存超时才能重新生成最新的页面,不过对于一些访问量不大或者主机资源极度贫瘠的站点来说,也算是一个让站点飞的方案。
  • 开启CSS JS压缩打包。使用Minify压缩并打包css和js文件,一般来说css或者js都是压缩过了,主要是要打包。一个页面中有很多css和js文件的话,浏览器要发出多个请求以获取这些文件,势必会影响加载速度,如果可以将页面中全部的css文件合并成一个文件,javascript合并成一个文件,那么浏览器只需要发出两个请求即可,绝对比多个请求快多了。w3 total cache中可开启Minify压缩打包功能,在实测中我开启js打包压缩,然而打包出来的这个js在浏览器中运行却一直死循环,估计有部分js可能打包过程中冲突或者错误之类的,css的压缩打包是没问题的。
  • 资源CDN中转。申请一个七牛CDN,在w3 total cache中开启CDN,针对多图的文章加载是绝对杠杠的,部分javascript文件和css文件也会通过指定的CDN链接进行加载。

可见w3 total cache是个非常强大的性能优化插件,不过现在站点的响应速度已经达到我的理想值了,除了CDN之外,其他的优化项对我来说是不需要了。

4 条评论

    1. wp的插件都是在后端执行的php脚本,他们的执行结果就是最后的页面输出内容,如果页面已经加载完了那么插件肯定已经处理完自己的工作了。如果要实现你这种需求,那么你的插件修改的页面那部分内容就要改成异步加载了,异步去请求后端插件数据

      1. 😛 😛 😛 好的,AJAX么,这个修改难度有点大呀,可以修改插件,为最后运行,还是最先运行么。

        1. 具体来说,插件功能实现都基于wp的钩子,影响插件功能执行顺序的是钩子的执行顺序,当然,钩子的执行顺序是可控的,在钩子注册的时候填入优先级参数即可,但是要留意如果钩子在最先执行可能执行结果会被后面的钩子覆盖,同理如果在最后执行,那么可能你的钩子处理的内容已经被上一个钩子修改过了(而不是原始内容)。不过这执行顺序可和响应时间没关系哦,最终响应时间正常来说应该还是一样的。

欢迎留言