石锅拌饭

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

最近这个星期，每天晚上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的时候，这点尤其总要。