阿里雲Redis加速Typecho部落格訪問

儘管只有小小256mb的容量，但是對於目前**的訪問量來說已足矣了。

繼上次，論壇加速飛起來之後，快取也就用了區區的50mb+左右，很顯然是有點浪費了。

前幾日，部落格也上了把安全套(https)，提公升了逼格並小小的裝逼了一下。都說加s會影響**的速度，顯然這是毋庸置疑的。儘管很早就上了阿里雲智慧型cdn，顯然擋不住我追求速度的極限。

突然，又好想裝逼了。

作業系統：linux centos 6.5

web伺服器：nginx/1.10.3

部落格程式：typecho

快取服務：阿里雲redis

快取外掛程式：tpcache

tpcache是減緩**併發壓力而開發的快取外掛程式，支援memcache，redis，mysql三種驅動。

這裡，需要注意的是，外掛程式本身是不支援密碼訪問的。由於阿里雲的redis服務需要密碼訪問，就簡單的修改了一下typecho_redis.class.php檔案(部分**)：

public function init($option)
catch (exception $e)
}

由於部落格是支援https的，所以選擇了開啟支援ssl。

由於使用的是阿里雲的redis服務，這裡只需要配置phpredis並開啟redis擴充套件即可。

redis配置參考：阿里雲redis加速discuz論壇訪問

後台文章或頁面更新

重啟redis

快取到期

ab(apache benchmark) - apache自帶的乙個測試工具，一般把apache壓力測試稱為ab測試。

我們可以模擬10個併發使用者，對乙個頁面傳送100個請求。

ab -c 10 -n 100

我們這裡，隨便取幾個引數做對比。

//整個測試持續的時間 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)

//整個測試持續的時間 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)

測試分析，簡單的對比以上引數，效果還是比較顯著的。

阿里雲Redis加速Typecho部落格訪問

Docker 阿里雲映象加速

阿里雲容器映象加速

阿里雲Redis賬號

阿里雲Redis加速Typecho部落格訪問

Docker 阿里雲映象加速

阿里雲容器映象加速

阿里雲Redis賬號

相關推薦