石锅拌饭

做财帮子，一个直接的收获就是一些理财和金融的知识，上证指数陪着我们从3000点杀到6000点，又跌到现在的2748点，更可谓刺激非常。

今天和一个朋友聊起股市，他说他自己现在满仓，亏得不敢看。我自己在6000点的时候是2/3债券基金，1/3股票型基金，跌到3500点的时候，转换了一部分债券型到股票型，两个月前开始定投股票型基金，目前接近60%的股票型，40%的债券型。累计收益-18%，超过81%的财迷。

很多人都骂中国的股市不理性，可很少有人细究为什么会这样，更多的人乐于把责任推卸给政府、证监会、机构或者当年忽悠他们进场的人。要我说，的确有这样那样的原因，但是股市是股民组成，股市的不理性正是股民的不理性的反映，是我们的股民造就了我们的股市，不是别人。06/07年的股市暴涨让多少本来理性的人失去了理性，又让更多本来没什么理性可言的人冲进了市场，泡沫就是这样起来的。

也总有人在这个时候质疑为什么政府不救市。股市上涨的时候是没有人喜欢政府来干预市场经济的，去年调高印花税，不知道多少人骂呢。我并不是来开脱谁的责任，但如果已经有人通过一些手段来告诉你风险很高了，你没有听，还要他怎么救你呢？还有我也想不出该怎么救市，如果政府真有什么有效的干预手段让救股市到规规矩矩回到6000点，手段一出，招来的就是索罗斯们。如果这次学费白交了，下次只能还做受害者。

我选择这个时候开始定投，并不是说我认为现在是底了，我不是来抄底的，只是觉得现在比较低了，去年11月份之前，相信每个人都会想，如果2700点有一次进的机会该有多好，现在还有多少人把这看成机会呢？我选择定投而不是一下全赌进去，如果股市再跌，那么下个月我可以买到更便宜的基金，熊市时间越长，我能够收集的筹码越多，总有涨上去的那天。这就是定投的好处。

这些都是我和朋友谈的对现在市场的看法，我肯定不是什么专家，不过是经过这一年的一些所得。

今天好像是什么css裸奔节，也让财帮子的用户首页裸奔了一下，为没有看到的朋友准备了截图：

Read the rest of this entry »

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

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