博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
阿里云Redis加速Typecho博客访问
阅读量:5874 次
发布时间:2019-06-19

本文共 2199 字,大约阅读时间需要 7 分钟。

写在开始

一不小心,博主趁着阿里云搞活动,一口气把Redis服务续费了3年(到期时间:2021-05-03,不知那时候博客是否健在?)

尽管只有小小256MB的容量,但是对于目前网站的访问量来说已足矣了。

继上次,论坛加速飞起来之后,缓存也就用了区区的50MB+左右,很显然是有点浪费了。

redis.png

前几日,博客也上了把安全套(HTTPS),提升了逼格并小小的装逼了一下。都说加S会影响网站的速度,显然这是毋庸置疑的。尽管很早就上了阿里云智能CDN,显然挡不住我追求速度的极限。

突然,又好想装逼了。

8.gif

相关环境

操作系统:Linux centos 6.5

Web服务器:nginx/1.10.3
博客程序:Typecho
缓存服务:阿里云Redis
缓存插件:TpCache

安装插件

TpCache是减缓网站并发压力而开发的缓存插件,支持Memcache,Redis,Mysql三种驱动。

下载地址:

后台设置

下载-解压-重命名为TpCache-后台启用即可,如图:

123456.png

这里,需要注意的是,插件本身是不支持密码访问的。由于阿里云的Redis服务需要密码访问,就简单的修改了一下typecho_redis.class.php文件(部分代码):

public function init($option)    {        try{            $this->redis = new Redis();            $this->redis->connect($this->host, $this->port);            $this->redis->auth('redis密码');        }catch (Exception $e){            echo $e->getMessage();        }    }

由于博客是支持https的,所以选择了开启支持SSL。

组件支持

由于使用的是阿里云的Redis服务,这里只需要配置phpredis并开启redis扩展即可。

redis配置参考:

缓存更新机制

  • 来自原生评论系统的评论
  • 后台文章或页面更新
  • 重启redis
  • 缓存到期

测试分析

ab(apache benchmark) - apache自带的一个测试工具,一般把apache压力测试称为AB测试。

我们可以模拟10个并发用户,对一个页面发送100个请求。

ab -c 10 -n 100 https://blog.52itstyle.com/archives/186/

我们这里,随便取几个参数做对比。

开启Redis缓存前

//整个测试持续的时间Time taken for tests:   23.176 seconds //大家最关心的指标之一,相当于 LR 中的 每秒事务数 ,后面括号中的 mean 表示这是一个平均值Requests per second:    4.31 [#/sec](mean)//大家最关心的指标之二,相当于 LR 中的 平均事务响应时间 ,后面括号中的 mean 表示这是一个平均值Time per request:       2317.623 [ms](mean)//平均每秒网络上的流量,可以帮助排除是否存在网络流量过大导致响应时间延长的问题Transfer rate:          139.82 [Kbytes/sec] received//整个场景中所有请求的响应情况ercentage of the requests served within a certain time (ms)  50%   1071  66%   1304  75%   1693  80%   1874  90%   2705  95%   4462  98%  14752  99%  15347 100%  15347 (longest request)

开启Redis缓存后

//整个测试持续的时间Time taken for tests:   15.917 seconds//大家最关心的指标之一,相当于 LR 中的 每秒事务数 ,后面括号中的 mean 表示这是一个平均值Requests per second:    6.28 [#/sec](mean)//大家最关心的指标之二,相当于 LR 中的 平均事务响应时间 ,后面括号中的 mean 表示这是一个平均值Time per request:       1591.713 [ms](mean)//平均每秒网络上的流量,可以帮助排除是否存在网络流量过大导致响应时间延长的问题Transfer rate:          203.40 [Kbytes/sec] received//整个场景中所有请求的响应情况Percentage of the requests served within a certain time (ms)  50%   1263  66%   1491  75%   1816  80%   1987  90%   2507  95%   3917  98%   4049  99%   4658 100%   4658 (longest request)

测试分析,简单的对比以上参数,效果还是比较显著的。

转载地址:http://ysenx.baihongyu.com/

你可能感兴趣的文章
WinForm基础
查看>>
初学类和对象
查看>>
XML 反序列化为Model
查看>>
一些感想
查看>>
SDL2 undefined reference to `SDL_Init' 问题
查看>>
蓝天集团董事长郎凤娥专访
查看>>
类成员与方法访问控制从严
查看>>
JSF是什么?它与Struts是什么关系?
查看>>
51 nod 1405 树的距离之和
查看>>
BZOJ 2733: [HNOI2012]永无乡
查看>>
spring 线程安全
查看>>
面试十大难题的样板回答
查看>>
梦断代码读后感(一)
查看>>
1489 蜥蜴和地下室
查看>>
Linux服务-bind
查看>>
SpringMVC系列(十六)Spring MVC与Struts2的对比
查看>>
20061008: IntelliJ Idea 6
查看>>
Android IOS WebRTC 音视频开发总结(四一)-- QQ和webrtc打洞能力pk
查看>>
Immediately register your GHD frizzy hair straightener concerning the GHD web page
查看>>
清除Xcode缓存
查看>>