Home

zhangyiqun

Thoughts, stories and ideas.

2014年以前 About Feed

08 Dec 2009
如何使用cdn加速wordpress?

一。概述

很多朋友可能像我一样将blog放在国外的主机上,虽然享受了实惠的价格可在访问速度上肯定要比国内略逊一筹。显然这个时候的瓶颈在网络层和传输层上,缓存类的插件效果非常有限。形象点说这个就像卡车拉了一车货,有大有小,网络环境就像公路。远在海外的服务器要拉货回国自然要走相当长的一段路,光从长度来讲就已经很长了,路上在走点弯路颠路速度肯定大打折扣。此时可以通过cdn来加速页面访问,cdn简而言之就是一辆距用户最近的卡车。

什么货物可以放在CDN上?

图片,js,css,音频……简言之就是网站中的“静态”内容

如何搭建CDN服务器?

可以通过apache,squid等来实现,这个课程不在本文范围。

是不是必须要有CDN服务器?

不是,商业的CDN有自己租用的线路,自己走路由。本文所用的只是CDN的概念。

使用什么插件实现?

本次使用的插件是W3 Total Cache

二。本文读者

使用独立主机的用户

有vps的用户

对主机有自主权的用户

linux爱好者

wordpress加速发烧友

本文主要讲解如何让海外服务器和本地搭建的cdn实时同步

三。实现

1.一台cdn服务器(当然数量越多越好)

2.inotify-tools (安装在海外服务器用来实时同步数据)

3.内核支持inotify (海外服务器)

四。操作步骤

以下所有操作全部在海外主机中进行,并假设cdn服务器已存在

确定内核是否支持inotify

$ls -l /proc/sys/fs/inotify/

-rw-r–r– 1 ludy ludy 0 2008-12-16 14:40 max_queued_events

-rw-r–r– 1 ludy ludy 0 2008-12-16 14:40 max_user_instances

-rw-r–r– 1 root root 0 2008-12-16 09:07 max_user_watches

下载tool

wget http://downloads.sourceforge.net/project/inotify-tools/inotify-tools/3.13/inotify-tools-3.13.tar.gz?use_mirror=cdnetworks-kr-1

安装tool

mkdir ~/apps

./configure –prefix=/home/jean/apps/inotify

make

make install

建立服务器信任关系

ssh-keygen -t rsa

scp .ssh/id_rsa.pub to Bmachin B

cat id_rsa.pub ».ssh/authorized_keys

chmod 644 authorized_keys

建立好后记得测试一下是否可用

编辑同步脚本。我的拿上来作示范,每个人的配置不同请不要照抄否则可能导致数据被覆盖。

#!/bin/sh

SRC=/home/jean/zhangyiqun.cn

DST=user@ip:/var/www/html

INWT=/home/jean/apps/inotify/bin/inotifywait

RSYNC=/usr/bin/rsync

$INWT -mrq -e create,move,delete,modify $SRC while read D E F;do

rsync -aHqzt $SRC $DST

done

常见错误

1.Unable to create table wp_w3tc_cdn_queue: Can’t create table ‘wp_w3tc_cdn_queue’ (errno: 24)

To fix this remove “DEFAULT CHARSET=latin1” from SQL in /w3-total-cache/lib/W3/Plugin/Cdn.php. This bug will be fixed in the next release.

按照作者的方法问题还没得到解决登录后发现数据库内部错误……

参考资料

http://deidara.blog.51cto.com/400447/120008

http://floss.blog.51cto.com/683157/138088

为什么使用 inotify?
使用 inotify 取代 dnotify 的原因有很多。第一个原因是,dnotify 需要您为每个打算监控是否发生改变的目录打开一个文件描述符。当同时监控多个目录时,这会消耗大量的资源,因为有可能达到每个进程的文件描述符限制。
除此之外,文件描述符会锁定目录,不允许卸载(unmount)支持的设备,这在存在可移动介质的环境中会引发问题。在使用 inotify 时,如果正在监控被卸载的文件系统上的文件,那么监控会被自动移除并且您会接收到一个卸载事件。
dnotify 不如 inotify 的第二个原因是 dnotify 有点复杂。注意,使用 dnotify 基础设施的简单文件系统监控粒度只停留于目录级别。为了使用 dnotify 进行更细粒度的监控,应用程序编程人员必须为每个受监控的目录保留一个 stat 结构的缓存。该用户空间的 stat 结构缓存需要用来明确确定当接收到通知信号时目录发生了什么变化。当获得通知信号时,生成 stat 结构列表并与最新的状态相比较。显而易见,这种技术是不理想的。
inotify 的另一个优点是它使用文件描述符作为基本接口,使应用程序开发者使用 selectpoll 来监控设备。这允许有效的多路 I/O 和与 Glib 的 mainloop 的集成。相反,dnotify 所使用的信号常常使程序员头疼并且感觉不太优雅。

inotify 通过提供一个更优雅的 API 解决了这些问题,该 API 使用最少的文件描述符,并确保更细粒度的监控。与 inotify 的通信是通过设备节点提供的。基于以上原因,对于监控 Linux 2.6 平台上的文件,inotify 是您最明智的选择。


zhangyiqun

scribble

2014年以前 About Feed