网站建设

解决网站静态缓存后WP-PostViews插件不计数的问题

突然发现文章浏览计数功能失效了,文章发了几个月才几十上百的浏览数,本以为是因为最近发的文章都比较冷门,不受欢迎。但是发布了几个月,才不到2百的访问量,这就不合理了。 一、发现问题 于是花时间分析了下,结果一查网站日志,发现浏览计数的请求居然一个都没有。。。 由于网站开启了纯静态缓存(nginx_fastcgi_cache),所以wp-postviews的计数方式会自动改为ajax提交方式,正常情况下,Nginx日志里面会出现如下请求记录: 而我翻看了最近半个月的Nginx日志,只有寥寥数条,看来确实有情况。 二、解决问题 首先,我打开了一篇文章,按下F12,再刷新该页面,在NetWork内容中搜索我熟悉的admin-ajax,发现没有记录,甚至搜索php关键词都没有任何请求记录,直接在页面源码中搜索关键词也是一无所获,看来确实没有浏览计数代码了。 我以为是更新了WP导致PostViews插件不工作了,于是打开WP-PostViews源码看了下,发现有如下逻辑代码: 发现了开启ajax计数的必要条件:开启WP_CACHE缓存!!!!! 鉴于对WP的熟悉程度,我直接打开了wp-config.php文件,发现果然是我自己注释了如下代码: 估计是之前调试网站的时候注释掉了。 于是取消注释,重载php-fpm,并清理Nginx静态缓存后,前台熟悉的ajax代码就回来了: 再看了下Nginx日志,admin-ajax.php?xxx的请求也回来了,看来浏览计数功能已恢复正常。 三、结论分析 ①、为什么并非完全不计数或只计数一次? 回溯了下过程,很明显的发现,文章发布后还是有计数的,只是计数非常少,这是为什么?实际上,原因非常简单,文章在首次缓存的时候,WP-PostViews其实是会工作一次的,使用的是非缓存环境下的php计数。计数之后,文章就缓存下来了,再次访问就不会再更新计数了,直到有人发表了评论或者缓存到期,导致缓存被刷新,才会再一次发起浏览计数!这就是为啥并非不计数或只计数一次的原因了。 ②、WP-PostViews缓存环境下计数的条件 这个问题很常见,刚我还搜了下,发现也有不少和我这个类似的情况。也就说,PostViews插件会去判断WP是否开启了缓存(WP_CACHE),若开启了则使用ajax的计数方式,否则使用php计数方式。 因此,如果你使用的是非PHP的缓存机制,比如Nginx的fastcgi_cache或者proxy_cahe,那么必须在wp-config.php里面开启WP_CACHE: 让插件知道你的网站是有缓存机制的。要不然,你就得修改插件,去掉这个判断,让插件强行在页面中插入ajax计数代码了。
阅读全文
WEB应用

WordPress启用memcached动态缓存以及报错解决

张戈博客目前用的是Nginx的fastcgi缓存方案,属于纯净态缓存模式,所以前台登录态什么的基本都没了。如果要兼顾前台登录态,又想速度快,有没有解决方案? 之前在分享张戈博客优化方案时提到,要实现网站轻度缓存,方案还是有的,比如 DB Cache Reloaded、Redis、memcached等。 最近恰好遇到一个数据缓存需求,因此尝试了下memcached方案,下面简单分享下我的环境部署以及报错解决过程。 一、d还是不d php有memcached和memcache两个类似组件,百度搜出来的文章,大部分是教你如何安装memcache(d),却步解释二者的区别。 比如这位博客仁兄的经验分享: 为什么他选第二个不行?其实php的这2个组件还是有点区别的: 简单来说: memcache 是 pecl 扩展库版本,原生支持php,出现更早,是老前辈; memcached 是 libmemcached 版本,出现较后,是新一代,因此也更加完善,推荐使用。 Ps:如果想更深入了解,可以搜索下 memcache vs memcached 其实,我们这种小网站的话,二选一即可,这点QPS还不至于纠结。不过一旦选择了,安装的时候就要注意区分,一对一配套安装,别搞的牛头不对马嘴,出现上面那位仁兄的困惑(后文有相关说明)。 这里,我果断选择了带d的,继续分享。 二、部署memcached 1、安装memcached Ps:这里的memcached是指Mencached的服务端,用来处理缓存数据,名字也是容易混淆。 下面2种安装方式任选其一: ①、在线安装 ②、编译安装 相比在线安装,很多时候编译安装更加灵活,非常类似Windows平台的自定义安装或绿色安装,推荐熟悉 Linux 系统的朋友使用: 至此memcached的服务端就安装好了。 2、集成php-memcached拓展 ①、先安装libmemcached 提前分享一个问题,如果直接按照网上的教程安装php-memcached可能会报如下错误: configure: error: no, sasl.h is not available. Run configure with --disable-memcached-sasl to disable this check 大部分教程会使用 --disable-memcached-sasl 参数来禁用这个功能,作为一个强迫症,我还是从国外的论坛扒到了解决方法,很简单,在编译libmemcached之前,先安装cyrus-sasl-devel即可解决 接着开始编译安装libmemcached: ②、安装php-memcached组件 下载和解压这步,我们要区分下是php7还是之前的版本: I、如果当前环境是php7 : II、如果是旧的的php版本: 接下来开始编译: 编辑php.ini文件,在最后插入如下参数 Ps:如果不知道php.ini在哪个位置 ? 执行命令:php --ini 即可找到。 保存后,执行如下命令看看是否加载成功: 如果输出memcached则表示成功。 最后,如果是Nginx就 service php-fpm reload ,如果是Apache就重启Apache完成安装。 ③、测试缓存 将上述代码保存为 test.php,然后执行 php -f test.php,如果能输出100表示安装成功。 三、WordPress缓存 做完上述所有步骤,系统环境就已经支持memcached缓存了。下面分享如何应用到WordPress 1、安装插件 访问github项目页面下载插件包: https://github.com/tollmanz/wordpress-pecl-memcached-object-cache 下载并解压得到的 object-cache.php,上传到 wp-content 目录即可开启memcached缓存。 值得说明的是,这里还有一个大坑等着你来踩: WordPress官网上的object-cache.php虽然也号称Memcached 插件,然而它只支持Memcache,不支持新版的,所以不能使用。如果错误地将object-cache.php和Memcached混用的话,则会出现WordPress打不开,前台后台页面一片空白的现象。 这也就是经常有站长反馈WordPress启用memcached功能后,页面空白的错误原因了。不巧,张戈在测试的时候也踩坑了,所以特别提出来,希望大家了解错误的原因,规避掉!   2、查看效果 做完第2步之后,你可以去网站前台刷新几次,产生缓存,然后从官方下载探针: http://pecl.php.net/get/memcache-3.0.8.tgz 解压后,里面有一个memcache.php文件,编辑并找到如下代码: 修改如下:...
阅读全文
WEB应用

实测Nginx服务器开启pagespeed加速效果

上周有一个站长问到我一个问题,问fastcgi_cache和pagespeed加速有没有冲突。略微想了下,2个都是比较原生的主,应该不存在兼容问题。 至于这个朋友问到这2个机制处理的先后问题,我思考了下。既然fastcgi_cache已经是缓存到本地的文件,那么pagespeed肯定是后处理的。通俗来说,就是当用户访问WEB时,Nginx 应该是先调用 fastcgi缓存,然后再进行pagespeed优化处理,最后返回数据给用户。 当然,经过我最后的测试,也证实了我的猜测是正确的。 一、还能再快 张戈博客已经很快了,然而并没有什么L用,该抄袭的抄袭,模仿的模仿,关键词和流量都碎了一地。在这个互联网时代,张戈温馨提示一下,有什么好的创意或赚钱方法,绝逼不要透漏。唯有闷声发大财才是王道,因为这是一个没有道义、不讲章法的混乱时代!案例就不贴了,看到张戈博客某篇博客排名好,指数高,各种模仿,那标题拟的和张戈博客亲生似的。某度也是一个大煞笔,什么垃圾辨识度,不识原创为何物,真是无力吐槽!好久没在文章中吐槽了,真是憋着荒! 回到文章,分享还得继续... 印象中张戈博客从51CTO转载过一篇pagespeed相关文章,但是一直也没去尝试一下。搜索一下发现是2年前的教程: 借助PageSpeed,为Nginx网站服务器提速 这次正好周末有空,就果断重新编译了一下Nginx,测试了一把 pagespeed。最终还是不负众望,效果比较满意。如果想网站速度更进一步,可以跟着本文走一遍。 二、重新编译 大伙大概也发现了,编译nginx 是折腾它的基本功,如果你还不会,那就看下张戈博客以前分享的文章,学好这个基本功再来玩: Nginx在线服务状态下平滑升级或新增模块的详细操作记录 一般来说新增编译一个模块,只要提供这个模块的下载地址,编译应该就没多大问题了。 本文模块下载及编译参考: 三、修改配置 编辑网站的nginx配置文件,比如 zhang.ge.conf,在server模块里面加入如下代码: 然后,新增缓存文件夹: 最后,重启Nginx即可生效(实测发现这个模块的修改必须重启nginx,reload是无效的...),发现很多朋友不知道如何重启nginx,然后看到要重启就把服务器重启了下,虽然也可以,但是也太暴力了点吧? 通过工具安装nginx,一般都带有service控制,可以使用如下命令重启nginx 实在没有,也可以先kill掉,再启动: Ps:那些用面板的朋友可别说不是这个路径啥的, 谁要你用面板。。。这也是面板蛋疼的一点,路径个性不一,自己撸去吧。 四、测试效果 ①、看源码 好了,重启Nginx后,咱们刷新一下前台,随便搜索下 pagespeed,可以发现源码大部分都已经被替换了: 如图,绝大部分js、css的url都变了,被合并成了一个url。 体积小点的图片,比如表情,被转成了浏览器编码的形式,算是减少服务器请求的一种优化: 看起来优化后,html代码变多了很多,于是下载看了下: 果然, 同一个页面开启后,大了20多k!尼玛,要是其他地方没有大的改善,这绝逼有点吓人了,于是继续看看。 ②、看图片 接着,看了下文章缩略图,发现还能压缩图片体积: 比如未启用pagespeed之前的图片大小【图片地址】: 开启后:【图片地址】 尼玛,十多倍的差异,让我有点不信邪。于是下载到电脑看下: 这下差异确实小了点,大概2倍多。但是,后者本是WebP格式,也就是谷歌(google)开发的一种旨在加快图片加载速度的图片格式。我下载到本地后会自动转成了jpge格式,体积肯定是有所变化!总的来说,这压缩效果真的很明显!不过经过我多次验证,发现并非所有图片都有这个效果,估计和原本图片的压缩程度有关系。 ③、工具测 光靠肉眼,有点无力。pagespeed 主要用来加快浏览器的渲染加载,所以我决定用下阿里测分析下加速前后的区别。 优化前的测试报告: 报告地址:http://www.alibench.com/rp/f9a4c1a8ddd267e0897613501dd2b422 优化后的测试报告: 报告地址:http://www.alibench.com/rp/17778d646ca7133609cc348b77096f37 点开一下加载详情对比了下: 优化前: 优化后: 效果还是很明显的,感兴趣的可以自己点开报告地址,查看更详细的对比!当然也推荐喜欢折腾的朋友尝试一下开启 Nginx 服务器 pagespeed加速!如果是 Apache 服务器,可以集成 mod_pagespeed,感兴趣的自己去找资料折腾吧! 最新补充:张戈博客体验了几天,发现一个问题:启用这玩意之后,CPU占用会比较高,Nginx 经常100%,虽然存在静态缓存,但是网站后台偶尔会比较卡,暂时已取消这个功能。所以对于使用单核CPU的云服务器就不建议折腾这个玩意了。
阅读全文
网站建设

解决Nginx Helper插件一键清理缓存功能导致网站打不开问题

5月份,张戈博客分享了一篇《Nginx开启fastcgi_cache缓存加速,支持html伪静态页面》的文章。文中也提到了 WordPress 有一款名为 Nginx Helper 的插件是这个功能的绝佳搭配。 一、问题描述 不过,最近通过朋友反馈及我自己亲测发现了一个严重的问题: Nginx Helper 设置界面有一个一键清理缓存的按钮【Purge Entire Cache】,只要在后台点击这个按钮,前台就跪了。当然,如果对登录用户不显示缓存,那么登录用户访问是正常的。 二、分析原因 分析了一下原因:【Purge Entire Cache】这个按钮按下后会删除 Nginx 所有的缓存,但是却不会重载(启)Nginx。那么问题来了,当在前台请求需要展示缓存的页面时,Nginx 将继续调用之前的缓存文件,然而所有缓存文件却被这个插件删除了,所以这个页面就502了! 清理前可以看到如图缓存文件夹: 但是清理后,就没了,而且也不会在生成。因为这样强行全部删除并没有“通知”Nginx ...这时候,网站就打不开了。当然,如果是设置了登录用户或已评论用户不展示缓存,那么网站会实时展示正常打开。但是要展示缓存页面就会502了,因为 Nginx 自己都找不到路径了。。。 三、部署解决 不难理解,要解决这个问题,比如给一键清理功能绑定一个重载 Nginx 的机制。但是一般情况下 php并没有权限去重载或重启 Nginx 。所以,要继续使用这个一键清理功能,就只能授予 php 重启 Nginx 的权限,还需要将重启 Nginx 的命令集成到插件才行。 ①、授权php执行系统命令 php 重启 nginx 功能,张戈博客之前已经分享过相应的办法了,请先参考部署该功能: php平滑重启nginx,彻底清除WordPress的静态缓存 ②、将重载命令加入到一键清理函数 部署OK之后,编辑 Nginx helper插件下的 purger.php 文件,找到如下函数: 如下在函数中添加重载nginx的代码即可: 好了,现在点击一键清理功能,缓存会全部删除,而且nginx也会重载,前台网站也就不会跪了。 四、其他完善 当然,经常有人反馈偶尔更新文章,前台并不会刷新。其实,这本文陈述的情况也有关系。在使用【删除模式】时,单篇文章的缓存被清理后,也不会重载 Nginx。此时,如果此文的缓存是存放在内存的话,前台肯定就不会刷新了! 所以,我们有必要给单个清理功能也绑定一个重载Nginx的机制。此处为了节省数千个字,张戈决定提供全部修改好的 Nginx Helper 插件,需要的自行下载重新安装这个插件即可: 你可能会疑问为毛删除单个页面后,这个页面却还能打开?和删除全部不是一样的机制吗? 分析了下,如果类比删除全部缓存带来的问题,删除单个页面应该也会出现该页面打不开的情况才对。不过,细想了一下,解释很简单。因为删除全部缓存会破坏缓存的文件目录结构,而删除单个页面只是删除一个缓存文件,缓存的目录结构并未被破坏。 通俗来说:缓存的目录结构如同 Nginx 的一个行车路线,只有不破坏这个路径,才能正常行驶。当然了,你破坏了这个行车路线,重载一下 Nginx 它又能重新规划了。 五、更多花絮 当我发现这个问题,并解决后,还给这插件的作者发了BUG反馈邮件。蹩脚的中式英语并不影响交流,哈哈! 感兴趣的可以凑合看看: Hello Zhang Ge, Thanks for contacting us. This is Dinesh from rtCamp. Sorry to hear about the problem you are facing. Please verify if the Nginx Helper plugin is properly configured from its...
阅读全文
网站建设

WordPress集成PHP缩略图,并开启Nginx缓存的方法

之前张戈博客分享过一篇给 WordPress 开启 Nginx 缩略图的教程,用着确实不错!但是总感觉清晰度不敢恭维,就算将裁剪质量调到90依然失真严重,于是想另辟蹊径。 想起之前帮一个站长做CC防御的时候,发现他的网站就算被纯静态化,被攻击时CPU依然狂飙。最后分析请求日志发现,所有的压力来自网站的 PHP 缩略图功能。这个 PHP 缩略图虽然可以将实时生成的图片缓存成文件,但是第二次被请求,PHP 依然需要进行一些很简单的判断,比如这个缩略图是否被缓存、缓存文件是否过期等。在海量IP的请求下,这些简单的PHP动态判断就成为了拖沓大户了! 这也就不难理解 WP-Super-Cache 的 php 缓存模式比 Mod_Rewrite 模式要慢的原因了!所以,静态缓存最终都要完全抛弃掉任何简单计算才能算是淋漓尽致! 好了,扯得有点远了。虽然这位站长同学后来抛弃了这个 PHP 缩略图功能,但是张戈却记忆深刻。当  Nginx 缩略图不给力时,我第一时间就想到了它。 这玩意在访问量过大时是个拖沓大户,但如果我想办法去掉其中的 PHP 动态判断呢?自然就能发挥到淋漓尽致了! 下面简单分享下张戈的做法。 一、加速思路 我顺藤摸瓜(之前那位站长朋友用的就是倡萌的 Wdone 主题),自然就在倡萌那找到了这个 PHP 缩略图的使用方法: 可以看到,这种传参肯定是存在动态判断的,所以要完全静态化,我首先就要修改这个缩略图形式。 很简单,延续之前分享的 Nginx 缩略图思路,把上面的 url 改成在图片地址最后带参数的模式,然后伪静态重写为上面的形式,最后通过 Nginx 实现纯静态缓存。 二、部署方法 ①、PHP代码 下载后解压得到 thumb 文件夹,编辑里面的 timthumb-config.php,按照注释修改下(可选)。 然后将整个文件夹上传到网站根目录,现在按照倡萌给出的 url 形式肯定就可以看到缩略图了。 ②、Nginx规则 第①步能够正常看到缩略图效果后,我们接着部署Nginx规则。 在网站原有的Nginx规则中插入如下规则: 这样还只是重写了缩略图的 URL 形式,如果需要开启缓存,则需要用到 Nginx 的 fastcgi 缓存,还不熟悉的朋友请先参考张戈博客之前的分享: 《Nginx开启fastcgi_cache缓存加速,支持html伪静态页面》 按照之前的文章部署 fastcgi 缓存规则后,这个缩略图就被 Nginx 缓存了(在F12开发者模式中查看network头部信息即可看到 HIT from yourdomain.com),加载速度自然也就上来了! 三、主题修改 做完上述操作之后,还只是具备了这个缩略图功能,而实际应用到博客文章,总不能手工一个一个输入图片带上尺寸吧?而且还有一堆老文章也不可能人工修改一遍吧? 实际解决很简单,请参考如下代码: 修改原理: ①、将老文章中带尺寸的图片改成完整图片路径,我之前用的是300大小的图片缩略图,所以这里需要将高或宽300的全部去掉,变成完整尺寸图片路径; ②、最后将文章中所有图片路径上带上适合本文分享的尺寸规则,比如上述代码是?w=480,即图片缩略图统一改为480px大小。 好了,就分享这么多,有需求的朋友可以参考上面的代码,根据实际情况修改后加入到主题functions.php即可完美实现文章缩略图了。
阅读全文
网站建设

分享几个WordPress本地缓存gravatar评论头像的方案

由于GFW的关系,使用gravatar的博客评论头像经常会出现“图裂特效”,这肯定是很多站长小伙伴都遇到过的困扰。网络上也很多教程,通过更换 avatar的来源,来解决图裂的问题。确实可以解决图裂困扰,但是这头像的加载速度确实还有待提高,下面本文就分享3种将头像缓存到本地的方法。 一、代码方案 代码缓存方案来自 Willin Kan 大师,内容摘自 WP大学,以下是具体做法: ①、建立缓存目录 在wp-content 的同級目录建立一个文件夹,命名为 avatar ,设置该文件夹的权限为 0755 (如果 0755 不行,就试一下 0777)。 ②、设置默认头像 准备一张大小适合的默认头像,命名为"default.jpg" ,放在 avatar 文件夹里面。 ③、添加缓存代码 将下面的代码复制到模板的 functions.php 文件中即可: 二、插件方案 前不久,知更鸟博主鸟哥在begin群里分享了一款将gavatar头像缓存到本地的插件,个人试用了下,发现还不错,这款插件的名字就叫:nix-gravatar-cache。貌似原版插件有点问题,鸟哥还DIY了一把。 如果,发现装了原版的有问题,那么就下载鸟哥改过的版本吧! 三、Nginx方案 我在测试这个插件的过程中,看了下生效后的头像路径,突然灵感一现:这缓存完全可以通过Nginx的proxy反向代理来缓存到本地啊!就类似于方向代理谷歌,解决被墙问题。 说干就干,经过折腾测试,发现果然好用!下面分享一下具体做法。 ①、编译Nginx 如果你之前已经实操了过张戈博客分享的Nginx缓存教程,相信这一步就可以忽略。 Nginx 反向代理缓存需要集成 ngx_cache_purge 模块,如果没有,则需要重新编译Nginx,具体做法请参考张戈博客之前分享的文章: 《为网站开启Nginx缓存加速,支持html伪静态页面》之代理模式,新增该缓存模块,并在http上下文模块中添加proxy缓存规则,比如: ②、Nginx配置 在网站现有规则中加入如下规则,反向代理gavatar并缓存到本地: ③、PHP代码 在主题目录下的functions.php中插入如下代码: 即可将WordPress头像地址更改成自己的域名,因为头像地址二级目录字段是/avatar/,所以会匹配到我们在上一步Nginx新增的反向代理规则,从而从 cn.gravatar.com 拉取头像并缓存到服务器本地。 很明显这个方法支持各种建站程序(需要修改网站代码),比PHP代码或插件的逼格、效率都更高!而且还不会出现外部 url 地址了! 四、折腾拓展 上一篇文章,张戈博客分享了目前在用的优化方案,里面有一条是建议静态资源使用二级域名,并拒绝cookies的写入。所以本文还能继续拓展折腾一下:将头像地址改成二级域名。比如右键查看张戈博客评论头像,可以发现已经变成 res.zgboke.com 了。其实就是新增一个 res.zgboke.com 的 server 模块而已,非常简单,感兴趣的朋友可以自己折腾一下,本文就不多做说明了。
阅读全文