rss服务的一些优化
最近小组在做rss的一些调整,从中也发现了一些技术层面和非技术层面的问题:
技术层面:
目前的问题:
1:我们是通过前端缓存squid来提供rss服务的,rss服务抓取商一般是通过no-cache和页面url加随机数进行访问的.
而这也正是squid权限控制的一个"弊端",导致90%的请求都直接访问squid的后端,也就是说squid没有起到缓存的作用.
2:Rss地址过多(历史原因造成的),导致cache命中率过多.
3:由于rss服务特性和web服务特性的不一样,也因为cache命中率不高的原因,rss Squid的后端是专门的一组server.
解决的办法:
1:解决no-cache 穿透的问题,通过设置refresh_pattern -i .xml$ 11440 50% 22880 ignore-reload。
2:解决随机数访问url的问题:
squid的前端是nginx,主要作用是squid的分组hash和规则匹配.
而过滤url的随机数则需要在nginx上做(squid上做应该也是可以的).
location /rss/
{
if ( $request_method = POST ){
rewrite ^ $scheme://$host$uri redirect;
}
rewrite (.*) $1? break;
}
3:小镇挖掘比较深的一个问题是:增加随机数后会不会将同一份数据缓存在多个squid上,这样的话即使上面的规则匹配了,还是毫无用处的。
我们是通过url的完整地址做squid hash的,通过下面的配置解决这问题.
if ($request_uri ~* "^(/rss/.*\\.xml)" )
{
set $request_hash_key $1;
}
4:进一步挖掘,博客的前端squid在多个idc都是部署的,这样也许一个url的请求(假如各地都访问的话),则会造成对后端的访问。
修改配置比较简单,将各个idc的squid指向同一组squid即可,但从通用性考虑,这次可以先不考虑。
非技术层面:
1:上述的配置也许很简单,但通过尝试,可能会发现了一些大问题,也会挖掘的更身。
2:做一件事情很简单,重要的是持续的做下去,做到极限.
3:人与人之间的配合,态度是至关重要的.
建议继续学习:
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:ywdblog 来源: 技术 总结 记录 生活 工作
- 标签: rss
- 发布时间:2010-05-31 23:50:08
- [67] Go Reflect 性能
- [67] Oracle MTS模式下 进程地址与会话信
- [67] 如何拿下简短的域名
- [61] IOS安全–浅谈关于IOS加固的几种方法
- [60] 图书馆的世界纪录
- [59] 【社会化设计】自我(self)部分――欢迎区
- [58] android 开发入门
- [56] 视觉调整-设计师 vs. 逻辑
- [49] 给自己的字体课(一)——英文字体基础
- [47] 界面设计速成