AWstats 新版小记

刚在邮件列表里看到通知,AWstats 发布了 6.8 Beta 版。

上一次更新相比,新版本增加了特性不多:

Added OnlyUsers option.
Can show a full list for extrasection.
Can track RPC request.

如果要定制跟踪额外的访问信息,Extrasection 总是绕不过去的。还没测试这个版本,倒是希望这部分内容的配置能更清晰容易一些。

值得一提的是浏览器数据库的更新与 Patch 几乎都是中文搜索引擎与 Web 应用的爬虫相关,据我所知车东同学做了不少这方面的工作。

BTW: AWstats 堪称中小站点分析日志的不二之选。尽管这样,前段时间还是看到有些公司居然不了解这个好用的工具,嗯,推广之。

EOF

此文作者:, 位于 Web 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Movable Type 的性能问题

我算得上是 Movable Type 的忠实用户。这两年来,WordPress 快成为 独立 Blog 的标准配置了,MT 可以说每况愈下。自从升级到 MT4 之后,明显感觉 Blog 性能糟糕了很多,每一次发文章都要与 HTTP 500 错误战斗半天才能成功,读者留言也非常费劲,有段时间非常灰心丧气,都不想继续写下去了。如果说 MT 3 之前是与 SPAM 战斗,到了 MT 4 就完全是折腾性能问题了。虽然 MT 4 之后的每次小版本发布都宣称性能上有很大改进,实际表现总是欠佳。

一些常规的 MT 优化技巧 其实作用都不大,我还把 MT 用的数据库索引分析了一遍,删掉了好几个价值不大的索引,虽然不是无用功,但也解决不了问题,因为瓶颈根本不在 DB 这里。大多数 Movable Type 用户的应用场景是在 Dreamhost 上,在这个环境里要想找到应用的瓶颈还真的是个技术活。缺乏 Profiling 工具不说,如果调用某个命令消耗了资源稍微过份一点,立刻被系统 Kill 掉。

其实 MT 的设计思想还是很不错的,大部分页面都 Build 成静态页面,减少对数据库的压力。一般来说,这比 WordPress 频繁调用数据库的方式(当然 WP 是可以起用 Cache 的),应该在性能上有更好的表现才是。问题是 Dreamhost 对每个用户提供的硬件资源其实是很差的,尤其是磁盘 I/O 。我的所有页面加起来也不过几千个,如果只是访问静态页面或是数据库其实问题都不大的,麻烦出现在构建页面或者是遇到留言行为的时候,MT 会调用若干个磁盘上的模版文件,加上 Perl 本身的系统开销,消耗的资源就到了 Dreamhost 的极限,然后进程就被无情的 Kill 掉了。估计是用户群抱怨太多,从 MTOS 4.1.1 版本开始总算有了一个性能框架 专门用以分析性能问题(并且号召用户提供性能数据以便协助解决性能问题)。启用了一段时间后,收集到的 Log 响应时间典型是这样的:

MT::Template::build[Comment Response]=0.60070
MT::App::Comments::run=28.24320
Total=28.85665

或许在 I/O 不错的系统上,表现会好吧。Dreamhost 上文件都是放置在 NFS 上的,而且众多用户共用一个系统,只能将就一下。

今天看到 4.15 的改进中,已经可以 Cache Template Module 了。甘愿作小白鼠,升级。盼望这次能有效解决特定应用场景的性能问题。不过开启了性能 Log 看了半天,效果并非很显著,

后记:

经验证的有效办法之一

通过Cache提升MT基于Tag搜索的速度,只在第一次构建需要的 Tag 时候会占用平时一样的系统资源。再次搜索时,开销大大降低。”抱怨的同时要有解决办法”。

EOF

Facebook 的 PHP 性能与扩展性

炙手可热的 Facebook 是用 PHP 开发的。随着一些技术交流,逐渐能看到 Facebook 技术人员分享的经验。近期这个 geekSessions 站点上看到 Facebook 的 Lucas Nealan 分享的文档比较有参考价值。

Cache 为 王

任何一个成功的站点都有一套最合适自己的 Cache 策略。

Facebook_Cache_Level.png

Note:这个层次图画的稍微有点问题,不是严格从上到下的。

The Alternative PHP Cache , APC

Facebook 平均每个用户每天要访问超过 50 个页面,PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层,Facebook 采用了 APC

Lucas Nealan 的 PPT 举了一个例子,一个页面显示的时间从 4000 多毫秒降到了 100 多 毫秒。在 apc.stat 关闭的模式下,性能还要更好一些。不过需要重启动或用apc_cache_clear() 来通知更新。

PHP_APC.png

Memcached 层

APC Cache 的是非用户相关的信息,而用户相关的数据 Cache 当然是在 Memcached 中。

Facebook 部署了超过 400 台 Memcached 服务器,超过 5TB 的数据在 Memcached 中。这是当前世界上最大的 Memcached 集群了。也给 Memcached 贡献了不少代码,包括 UDP 的支持和性能上的提升(性能提升超过 20%)。

程序 Profiling

Facebook 开发人员大量采用 Callgrind 、APD、 xdebug 、KCachegrind 等工具进行基准性能测试。任何一个 Web 项目,这也是不可或缺,也是比较容易忽略的一环。所有开发人员都应该具备熟练使用这些工具的能力才好。

补充一下:语言的选择

为什么 Facebook 选择 PHP 而不是其他语言? 用Flickr 的 Cal Henderson 这句话就能说明了: “Languages’s don’t Scale, Architecture Scale”。

从 80-20 的原则看,APC 和 Memcached 是最主要的。在这两个环节上下功夫,受益/开销比要大于另外几个环节。

(上面的图是从 Lucas Nealan 的文档截的,版权所有是他的)
EOF

健康生活

上周六第一次进健身房。运动前,教练先给我进行了一下体能测试,结果我的结果是”虚弱”,需要大量增加肌肉。在跑步机上快走了一会儿,加上一阵小跑,出了点汗,感觉还不错。

今天冒着大雨又去了,差点浑身被浇透,可见心有多诚,还是在跑步机上折腾,不算太累。争取达到崔健说的“一周三次跑步加上一次游泳”,总算有时间梳理一下自己的生活了。

另外准备投入更少的时间在网上,纽约时报报道的那几个倒下的 Blogger 让人警醒。身体好才是正经事,前一段时间,家里亲人生病,心里闷了好久。有的时候光有钱也换不来健康。

EOF