Saturday, January 1st, 2011
很久以前在TW上挖了个坑，说nginx的fastcgi_cache是被大家忽视的一大金矿，今天把这个坑填上，顺祝大家新年快乐。
对于变化不太频繁的数据，大家都比较喜欢存Memcached以减少数据库的读取，但还是会有语言解析运行上的消耗（比如运行PHP，Python等），当然这个时间很短，记得OP上有个同学说P字头的语言，效率都不高，如果能省去，当然最好。（已经用上Squid等的可以忽略本文）。
还有一个问题就是很多时候一个页面由多个数据片断组成，为了提高页面速度，要么分别缓存，要么整体缓存（所谓的Page Cache），其实都比较麻烦，增加和减少数据片断的时，大多需要调整。
最后一个问题，所有的数据都存Memcached是否经济？服务器资源足够多的无所谓，捉襟见肘的就要考虑了，当然，生成静态页面是一种方法，需要维护，还是比较累。
好吧，nginx的fastcgi_cache可以解决上面的那些问题，比较squid等的好处是简单，不需再要去维护另外一个系统，适合不那么大的网站。
关于Nginx fastcgi_cache，基础的可以参看Nginx官方文档http://wiki.nginx.org/HttpFcgiModule，下面是一个典型的做法是：
fastcgi_temp_path /data/ngx_fcgi_tmp;
fastcgi_cache_path /data/ngx_fcgi_cache levels=2:2 keys_zone=ngx_fcgi_cache:512m inactive=1d max_size=40g;
fastcgi_cache_valid 200 301 302 1d;
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_cache_key $request_method://$host$request_uri;
注意一定要加上$request_method作为cache key，否则如果HEAD类型的先请求会导致后面的GET请求返回为空，全局定义一个缓存空间，配置文件名为，fastcgi_cache.conf，然后在vhost配置里面加上：
fastcgi_cache ngx_fcgi_cache;
include fastcgi.conf;
大概解释下各个参数的含义：
fastcgi_temp_path：生成fastcgi_cache临时文件目录
fastcgi_cache_path：fastcgi_cache缓存目录，可以设置目录哈希层级，比如2:2会生成256*256个字目录，keys_zone是这个缓存空间的名字，cache是用多少内存（这样热门的内容nginx直接放内存，提高访问速度），inactive表示默认失效时间，max_size表示最多用多少硬盘空间，需要注意的是fastcgi_cache缓存是先写在fastcgi_temp_path再移到fastcgi_cache_path，所以这两个目录最好在同一个分区，从0.8.9之后可以在不同的分区，不过还是建议放同一分区。
fastcgi_cache_valid：定义哪些http头要缓存
fastcgi_cache_use_stale：定义哪些情况下用过期缓存
fastcgi_cache_key：定义fastcgi_cache的key，示例中就以请求的URI作为缓存的key，Nginx会取这个key的md5作为缓存文件，如果设置了缓存哈希目录，Nginx会从后往前取相应的位数做为目录。
fastcgi_cache：用哪个缓存空间
这样就可以了，基本上可以work，但还没完，如何手动清除缓存？有个Nginx的第三方扩展可帮你做到：https://github.com/FRiCKLE/ngx_cache_purge/，如果对大多数第三方扩展无爱，写个清除的脚本也非常简单，以PHP为例：
Posted in PHP | 17 Comments »
Saturday, January 10th, 2009
本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2009/01/cu-net-opt-salon/
特意把调休放在1.9，主要是想去听听CU组织的网络优化论坛，报名的时候有点意外，貌似丢失了报名信息，和组织者沟通了一下，感谢周平同学的热心帮助，说到的时候找他就可以，去的时候其实也没有查邀请函什么的，还给了件CU的T-Shirt，甚是感谢，一般这种开源技术研讨会都是很开放的。
首先是TOM网的曹刚带来的“浅析系统架构”，主要讲的是Myspace和SOHU社区架构的演变过程，基本的内容可以参考构建可扩展网络应用的七个步骤，一般他们的历程都是从第一步到第四步，大体上差不多，我这里列举这个关键词：
64位：Myspace为了让服务器管理更多的内容，操作系统由32位升级到64位，我们都知道32位的操作系统最多支持4G内存（当然有方法可以实现超过4G，不推荐。），64位操作系统理论上支持4G个G，估计我是看不到用完的那天，这里要注意的是32位操作系统下，一个处理器最多处理2G内存，所以如果是Memcached服务器，不要一个进程给超过2G内存，浪费。好的做法是多开几个服务，或者直接把Memcached服务器和APP服务器合二为一，很多公司都这样。
分表：论坛的特点是数据一般是按照板块分组，所以对于论坛这样的应用来说，最好是按照板块ID分表甚至分库分机器。
板块帖子列表页：论坛的特性是新帖子、新更新的帖子排在最前面，所以可能的情况是每次刷新的时候页面都在变，SOHU社区的做法是把板块新帖子保持在一个链表里面，链表的特点是插入和删除都很快，问题是查询的时候只能遍历。
其实对于一个论坛板块来说，热门的帖子不会太多，估计大家也就翻前几页，大可以把这个数据放进缓存中，比如维护一个队列，最新的500个帖子ID，帖子Title，新帖子放在最前面，自动顶掉最后一个，大可以用数组而不用链表，虽然插入的时候慢点，读取的时候却不用遍历链表。
对于跟帖数据，一般都是按照时间顺序排列，新增加的帖子自动在最后，压力不会很大。
google去搜一下Carp算法，一致性哈希算法consistent hashing（可以参考http://tech.idv2.com/2008/08/17/memcached-pdf/），Amazon S3 环形算法（是不是就是consistent hashing?不知）。
曹刚最后做了个总结，个人觉得：熟悉业务需求应该是核心。
第二位演讲者是来自占座网的吴炳锡，讲的是LVS和Nginx的负载均衡，这块以前只是从资料上看过，接触比较少，不过炳锡的介绍深入浅出，以前觉得LVS晦涩难懂，不敢动手，听完之后无知者无畏了，有机会试试看去。其实很多事情都这样，看上去挺难，做起来就容易了，下面是几个关键字：
DR模式：LVS有NAT、TUN、DR模式，推荐使用DR模式，更多的信息去google吧。
LVS->Nginx->Squid：组合的模式，LVS是四层的转发，Nginx是七层的转发，可以支持URL规则的转发，组合起来用就可以随心所欲了。
性能：Nginx的性能和LVS NAT模式相当，都是很好的解决方案，熟悉哪个就用哪个吧，性能都不是问题。
keepalived：LVS居家旅行、杀人灭口必配武器。
搜房网：搜房网前端采用LVS做负载均衡，中间用Nginx做URL负载均衡，动态的URL跳到App服务器，静态的URL跳转到Squid服务器。
第三位演讲者来自某个赞助商，感谢他们对活动的赞助，就不做广告了，一句话概括：适合钱多人傻。
第四位演讲者来自SOHU的MySQL DBA叶金荣，报告的内容网上大多有，这里也列出一些关键字：
发现问题：系统响应慢、load avg >=5、IO wait >= 10、swap使用情况、mysql status、mysql report、mysql 5.1 profline
xfs：如果可能，mysql数据文件系统分区采用xfs，效果高30％～50％
innodb_buffer_pool_size：如果是专用的数据库服务器，设定为内存的80％吧
MyIsam适合低并发、低更新、高读取的需求，InnoDB适合高并发、高更新、高读取的需求，MyIsam读取的速度比InnoDB快许多。
Explain：查询检查、查询优化
联合索引：貌似MySQL一次查询只用到一个索引，联合索引要注意先后顺序的问题，“左派”比较吃香。
字段按需配置，能用TinyINT的不用INT，字段越短越好，具体差别可以参见：http://chaoqun.17348.com/2008/11/mysql-data-types-int/
把大表拆成小表，如果表字段里面有Text，尽量拆开吧。
缩短事务周期
字符型的字段，最好采用前缀索引。
复杂的查询拆成小的简单的查询，比如用循环查询替代。这点不敢苟同，还是按照自己的业务测试一下吧。一条sql语句总比N条要快吧，除非有问题。
left join：把条目数少的放左边，如果你了解left join的话，这个是肯定的。
实时备份：用slave做实时备份吧，一个slave就是一个备份。
第五个演讲最为精彩，走了的人实在可惜，掌声和笑声不断，田逸这个家伙说话太有意思的，有机会要认识一下。讲的是CDN方面的事情，关键字：策略，技术很重要，策略更重要。
昨天的网络优化论坛受益匪浅，演讲者都有丰富的经验，其实网站架构就那么点事情，多分享才能共同进步，不过从互动环节可以看出国内做技术的对这方面关注还是比较少，有些问题比较原始，多关注一些就不会那样了。
PS:报告盖茨：我上周四叛逃到Linux了。
Posted in Arch, Open Source | 3 Comments »