WEB应用

Nginx配置多站点下的Proxy_cache或Fastcgi_cache缓存加速

张戈博客分享过很多关于缓存加速的教程,自己也是不断的在摸索,追求最佳的网站静态缓存加速方案。在这里简单的总结一下: 1、使用虚拟主机的朋友推荐使用缓存插件或php 代码版缓存方案=>点此直达 2、使用独立主机的朋友推荐使用Nginx的Fastcgi纯静态缓存方案=>点此直达 在我分享了Nginx的Fastcgi缓存之后,有不少朋友已折腾成功。不过有朋友反馈,不知道在多站点下如何配置Nginx Fastcgi。而所有网上分享的方案都是单个站点的,我本以为多站点的直接在 php 的 location模块中插入fastcgi缓存配置就好了,结果发现会报错,提示缓存空间已被使用。 经过张戈轮番测试,最终试出了多站点下的Fastcgi缓存配置,下面简单分享下。 一、部署http模块 ①、单个站点 单个站点上篇文章已经分享过了,在http模块内加入如下配置即可: ②、多个站点 当要给多个站点开启fastcgi缓存时,以上配置就不行了,会报错。经过测试,修改如下即可: 二、部署server模块 配置好了http模块之后,server模块就很简单了! 只要在不同的站点的php模块下插入不同的fastcgi缓存配置即可,其实就是key_zone的区别而已。 比如,我同时给张戈博客和中国博客联盟2个站点的配置如下: 张戈博客: 中国博客联盟: 其实就是和http模块内定义的缓存一 一对应而已,这样才能区分开来啊!否则就会报错。 三、Proxy_cache缓存 分享了多站点的fastcgi缓存配置,顺带也分享一下Proxy_cache的多站点缓存配置好了。免得某些朋友不会依葫芦画瓢。。。 其实,我也没实际测试,但是依此类推应该如下配置即可,有需求的测试一番就知道了: ①、http模块 ②、server模块 至于server模块应该就不用跟上面介绍的那样详细了吧!不同站点只是 proxy_cache 这个配置不一样而已!比如: 站点1配置 站点2配置: Ps:可能有人又要问了,这配置是放到哪的啊?唉,就这样您还瞎折腾啥呢?老老实实写文章吧! 哦了,看懂以上配置,随便部署多少站点的fastcgi或proxy缓存都不用愁了!
阅读全文
WEB应用

Nginx在线服务状态下平滑升级或新增模块的详细操作记录

今天,产品那边发来需求,说有个APP的IOS版本下载包需要新增https协议,在景安购买了免费的SSL证书。当我往nginx上新增ssl时,发现服务器上的nginx居然没编译SSL模块! 看了下旧版本nginx的configure选项: 可能是出于最小化安装的考虑,就只有一个prefix参数,而版本也挺低的,干脆就升级一下好了!由于服务器处于在线服务状态,为了避免升级带来的不良影响,我决定给nginx来个平滑升级,结果发现还真是如丝般顺滑。。。 下面记录一下平滑升级和新增模块的过程。 一、半自动平滑升级 所谓半自动,其实就是在最后迁移的时候使用源码自带的升级命令:make upgrade来自动完成。 ①、按需编译新版本的nginx 根据需求,常规编译新版本nginx,不过只要执行到make就打住,不要make install! ②、重命名nginx旧版本二进制文件,即sbin目录下的nginx(期间nginx并不会停止服务!): ③、然后拷贝一份新编译的二进制文件: ④、在源码目录执行make upgrade开始升级: 完成后,最后确认一下 nginx -V : 正常了,平滑升级成功! 二、纯手动平滑升级 纯手动模式,指的是在最后做迁移的时候,全部使用手动命令来搞定,避免编译可能存在不一致的参数啥的。 实际上,在make之后,我们可以查看nginx源码目录下的Makefile内容如下: 所以,说白了纯手动就是执行upgrade标签下的命令行而已,实际上只要确认Makefile下的命令路径都是正确的,用命令自动迁移是没有任何问题的。 总是有人会不放心的,喜欢手动一步一步的搞定,我也来整理下纯手动步骤: ①~③和半自动一样,按常规步骤先编译nginx,不过只执行到make就打住,然后将旧的sbin下的nginx文件移走,再将编译得到的objs目录下的nginx文件放到原来的sbin目录。 ④、测试新版本的nginx是否正常: ⑤、给旧nginx发送平滑迁移信号(若不清楚pid路径就用可用命令(2)): Ps:后面其实就是旧nginx的pid,所以先用ps aux找到正在运行的nginx主进程pid,再执行 kill -USR2 PID值亦可。 ⑥、等待旧版本Nginx的pid变为oldbin(执行如下命令查看是否生成) ⑦、  从容关闭旧版本的Nginx进程 此时,旧的工作进程就都会慢慢随着任务执行完毕而退出,新版的Nginx的工作进程会逐渐取代旧版工作进程。 ⑧、此时,不重载配置启动旧工作进程(个人感觉是为了将任务完全切换到新的nginx上) ⑨、结束工作进程,完成此次升级操作: ⑩、最后,验证nginx是否升级成功: 特意测试了下纯手动的做法,下面是我的操作记录,仅供参考: 为了验证平滑升级确实不影响在线业务,我特意在升级的时候,利用ab命令一直在发送请求: 直到升级完成,使用ctrl +C 终止并查看ab结果,可以发现几十万次的请求全部成功,没有失败!证明平滑升级的可行性!可惜忘记了截图,感兴趣的童鞋可以自行测试下! 好了,关于nginx的平滑升级和在线新增模块的操作记录就到这里结束了,希望对你有所帮助。
阅读全文
网站建设

百度蜘蛛狂暴了!再次启用本地缓存,附nginx下wp super cache的mod_rewrite规则

昨天突然突然觉得后台很卡,前台由于开了360cdn倒没什么感觉。于是登录vps看了下access.log和netstat,发现BaiduSpider并发100+爬我的博客!搞的好像被攻击了一样,(/ □ \)。。。   补充:今天我特意看了下昨天的百度抓取情况,又吓了一跳: 虽然开了360CDN,但是对于搜索引擎的访问,360是直接回源的,所以蜘蛛的狂暴抓取压力就全部到了vps上了,CPU负载直接飙至14+,top里面php-fpm进程好生壮观,吓... 想了下,决定给本地来个静态缓存,让蜘蛛只能爬静态页面,减少php-fpm负载。首先装了一个Hyper Cache插件,发现新版的居然可以生成纯静态页面了,还挺欣喜的!观察了半小时,发现html是生成了,但是php-fpm占用依然很高!奇怪啊... 纳闷了半天,突然想起来,nginx本身不带Mod rewrite,那这Hyper Cache的静态重定向都是靠php实现的咯?我去,那前端访问还是把压力集中在php上了。 想起了一起用过的wp-super-cache是有Mod rewrite模式的,于是又换成WP Super Cache试了下,突然醒悟,Nginx并没有Apache的Rewrite_mod模块。网上看了下前人总结的教程,通过在配置文件里面加入规则实现了和Mod rewrite一样的功能: 只要将以下代码中的2~57行添加到网站对应的nginx location中即可: (代码出处:http://www.gongzi.org/nginxstartwp-super-cache-mod_rewrite.html) 由于我用的多说,所以其中30~33行是屏蔽的,直接全部展示缓存好了。 然后在回到WP Super Cache设置界面,跟往常一行开启Mod rewrite缓存模式即可,虽然插件会提示Mod rewrite模块丢失,但并不影响缓存页面的访问: 要验证效果,很简单,直接访问文章页面,查看源代码即可: 好了,这下百度蜘蛛再狂暴,也只能吃服务器的“残羹冷炙”了。
阅读全文