沫延说
沫延说

让使用WP Super Cache的WordPress站点访问速度再快几百毫秒

前言

一直以来我都在致力于以优化的形式提升站点访问速度

其实绝大多数站点访问速度不理想的原因都源自于以下几点:

  1. 服务器计算性能与网络带宽、静态资源加载;
  2. 中间件(代理程序)、运算器与数据库、缓存库的连接效率和速度、频率(次)
  3. 站点应用的代码执行效率与调用数据库、缓存等效率

其中服务器计算性能其实是最后才要考虑的问题,可以根据访问量或者说运算量而定,如果服务器平均负载长期低于0.3甚至长期低于0.2,且几乎不会出现峰值访问时负载0.80+,那大可不必升级服务器性能。这其实也是很多不重视信息化的公司的通病,跑个应用上来就高性能服务器,实际生产环境中服务器负载极地,实在是资源的浪费!

而中间件、运算器与数据库、缓存库的连接效率和速度、频率(次)问题也不是大众考虑的点,后面我也会专门抽时间谈谈公司级的优化方案。

对于使用WordPress程序的规模有限的企业(团队)或个人,网站的访问速度(或者说代码执行效率)对于用户体验来说是至关重要的,要知道用户1秒都不想多等

很久以前我就在使用WP Super Cache为我的WordPress站点提升执行效率,换来访问速度的提升

其原理是WP Super Cache将终端(用户)访问过的页面生成为静态页面(html)并保存至本地,下一个终端再次访问时,如果已经生成过静态页面,且未过期(不久前生成且动态页面内容未更改),则直接反回请求者(终端)已经生成好的静态页面,不需要代码执行(运算)器(即PHP)进行运算后再返回给请求者,这样一来的好处是大大降低了系统运算负载,节省了运算时间也就相当于提升了用户的访问速度。

然而这只是普通玩儿法,接下来说说更进阶一些的方案,再缩短几百毫秒的访问时间

以下方案仅适用于Nginx用户

 

进阶方案

一、开启WP Super Cache专家模式

WP Super Cache专家模式表面上看就是将配置写成了代码,加入在了伪静态规则中,实际上还是有一定的性能提升的,先说说使用Nginx中间件时的开启方法

将以下代码替换安装了WP Super Cache的WordPress站点的伪静态规则


set $cache_uri $request_uri;

# 将POST请求和带有查询字符串的url发送至PHP处理
if ($request_method = POST) {
        set $cache_uri 'null cache';
}

if ($query_string != "") {
        set $cache_uri 'null cache';
}   
 
# 不缓存符合下列规则的url
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
        set $cache_uri 'null cache';
}   

# 对已登录的和最近发表评论的用户不使用缓存页面
#if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
#        set $cache_uri 'null cache';
#}

# 对于未使用HTML5响应式技术的主题通过取消注释下列配置以适配手机端页面
# START
# if ($http_x_wap_profile) {
#        set $cache_uri 'null cache';
#}

#if ($http_profile) {
#        set $cache_uri 'null cache';
#}
 
#if ($http_user_agent ~* (2.0 MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo Wii|Nitro|Nokia|Opera Mini|Palm|PlayStation Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915 Obigo|LGE VX|webOS|Nokia5800)) {
 #       set $cache_uri 'null cache';
#}
 
#if ($http_user_agent ~* (w3c |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda |xda-)) {
  #      set $cache_uri 'null cache';
#}
# END
 
# 如果缓存文件存在则使用,否则将请求传递至WordPress
location / {
        try_files /你的缓存目录位置/SuperCache/$http_host/$cache_uri/index.html $uri $uri/ /index.php?$args ;
}    

注释中已将每一行的功能都描述清楚了,其中需要特别说明的一点是我并未开启“已登录用户不使用缓存”这个功能,是因为我的站点并无特殊的动态内容,不会影响正常功能使用

如有特殊需求的也可直接在代码上做更改

伪静态应用后将会由Nginx来辨别是否使用缓存好的静态文件还是交给WordPress程序(由PHP运算)

也就是说,原本的由WP Super Cache插件决定是否使用静态文件,变成了由Nginx来辨别,如果有未过期的静态缓存则返回给终端,相当于由Nginx直接展示静态页面,这样的好处是充分利用了Nginx优势,绕开了PHP代码的执行。

二、使用内存增强I/O速度

由系统、各种应用都在对硬盘进行读写,都会占用I/O。相比之下,内存的及时性和速度即便是固态硬盘肯定也是无法比拟的,即便是从硬件层面考虑,内存也一定是在总线上的,硬盘大多数都是在南桥,而南桥连接CPU相当于这么多设备共用PCIE x4,(当然了有一些板子的NVME除外,只是浪费几条主线换取硬盘速度的操作我觉得还有待推敲)

综上所述,如果将静态文件直接写入内存特定区域中,岂不是同样又能降低I/O负载又能提高响应速度?

况且静态文件一个几十kb到几百kb不等,按500kb一个静态页面已经足以囊括几乎所有站点了,那只需要50MB的内存可以存放一百个静态页面了,可谓是低成本高回报啊

其实这里说的静态文件并不准确,因为静态文件不仅指html,还包括字体、css、js等文件,而我们缓存的只有html文件,以下截图为淘宝网2020年双11购物节时的静态html文件大小

https://oss.topstalk.com/Blog-Datastore/2020/11/1647486497-taobaohtml.jpg

 

接下来是具体实施方法:

其实是创建了一个RAMDISK挂载在了静态页面生成的位置,按默认路径一般为WP_CONTENT_DIR. /cache/

也就是你的WordPress安装目录中的wp-content文件夹下的cache文件夹

如果使用的宝塔面板操作会简单一些,直接从软件商店找到“Linux工具箱”,里面有内存盘选项,注意建立内存盘时需要cache文件夹为空(里面没有文件),否则无法挂载上

非宝塔用户可以自行百度一下,需要调用到内核模块brd.ko,而且需要让他开机自动挂载,就不再赘述了

 

结语

根据我的测试,相对于不使用WP Super Cache时,#对称与非对称加密算法实现的简要解释与在互联网中的应用场景#文章的整体加载完成时间为2.71秒,其中html加载时间为938ms(不再精确计算去除CDN网络中css、js文件和广告的影响了,同时不考虑本地网络环境影响)

https://oss.topstalk.com/Blog-Datastore/2020/11/1647486626-webspeedtesta.jpg

未使用这两项加速措施,但是有WP Super Cache缓存的情况下,速度大概有800ms左右的差异,加载速度583ms,页面生成耗时: 0.29183,传输耗时292ms

https://oss.topstalk.com/Blog-Datastore/2020/11/1647486643-webspeedtesta2.jpg
https://oss.topstalk.com/Blog-Datastore/2020/11/1647486660-ymschs-1.jpg

使用这两项加速措施,相对于上个测试,速度大概有240ms左右的差异,基本上都是html贡献的加载时间..加载速度398ms,页面生成耗时: 0.27818,传输耗时120ms

 

https://oss.topstalk.com/Blog-Datastore/2020/11/1647486709-webspeedtestb.jpg
https://oss.topstalk.com/Blog-Datastore/2020/11/1647486752-ymschs.jpg

 

 

没有标签
首页      生产环境      优化技术      让使用WP Super Cache的WordPress站点访问速度再快几百毫秒

Morton.L

文章作者

发表回复

textsms
account_circle
email


沫延说

让使用WP Super Cache的WordPress站点访问速度再快几百毫秒
前言 一直以来我都在致力于以优化的形式提升站点访问速度 其实绝大多数站点访问速度不理想的原因都源自于以下几点: 服务器计算性能与网络带宽、静态资源加载; 中间件(代理…
扫描二维码继续阅读
2020-11-11