财帮子性能优化简报

财帮子从三月底正式上线到现在,已经快半年了,网站的流量差不多每月翻一翻。

最近这个星期,每天晚上8点到11点的高峰期,每个小时页面浏览一般在5万到7万,最高可以接近10万。除去由web server处理的静态文件等请求,每个小时由rails处理的请求从10万到30万,峰值可以达到200req/s。

与此同时,根据基金理财网站的特点,浏览高峰期,计算量高峰期和缓存失效高峰期刚好重合,我们接受的是比一般ruby on rails应用更严峻的挑战。

有人说财帮子已经是国内规模最大的ruby on rails应用之一了,这点我们无法考证,但随着量的增长,我们的确对ruby on rails的性能有了越来越多的认识。

别指望一劳永逸

从建站初期,我们就采取了各种性能优化的措施,SQLSession, Fragmeng Cache, Memcached…所有你能从教科书里看到的。但是,很多问题是慢慢暴露出来的,你需要根据实际情况来调整缓存策略,修改程序结构,优化算法,甚至优化rails本身。随着量的不断增长,碰到的问题会越来越特殊,书本、社区包括搜索引擎都很难再给你提供现成的解决方案,完全变成对你经验和能力的挑战。财帮子两个星期以前,遇到严重的性能问题,最终我们采用了相当非主流的部署方案和打了自己补丁的web server,成功度过了难关。

你不在美国

没有Google Adsense来养活你,人工费用和带宽、机位费也不成比例,你不可能有点性能问题就靠加服务器来解决。绝不是否定scale out的策略,但在此之前,一定要尽可能挖掘现有程序的潜力,发现已有和潜在的性能问题并解决。否则,盲目的scale out可能只是掩盖了真正的问题,并让你花冤枉钱。

rails不是你的SQL专家

activerecord成功封装了数据库接口,并提供了很多灵活便捷的功能。但是,完全依赖activerecord和ruby,你可能碰到严重的性能问题。find中的include和select选项能带来一些好处,但也非常有限。有时候你不得不写复杂难看的SQL,来代替优美的rails语句。rails纯粹主义在这时候不能为你赚到CPU。即便使用了缓存机制,而且缓存命中率很高,在访问量基数变大时,缓存释放和重建也有可能增大到相当的数量。数据库性能优化仍然是rails应用不可回避的问题。

log是你最好的朋友

log是所有性能调试的起点,从development log到production log,从rails log到web server log,不同的log有不同的侧重点,学会分析log,每个log都可能为你提供解决问题的蛛丝马迹。另外,要熟练使用benchmark结合log做profiling,当real time远大于db time + rendering time的时候,这点尤其总要。

12 thoughts on “财帮子性能优化简报

Comments are closed.