[链接] Top 10 Ruby on Rails performance tips

http://www.antoniocangiano.com/articles/2007/02/10/top-10-ruby-on-rails-performance-tips

这是一篇关于提高RoR应用性能的文章，提高RoR性能有两个途径，一个是服务器端配置，一个是在Rails这一块的调整，此文侧重于后者。主要的内容包括：

1- 在Ruby代码级别采用更优的方案；
2- 充分利用缓存；
3- 充分挖掘数据库潜力；
4- 合理使用finder查找函数；
5- 合并数据库事务；
6- 控制好你的控制器，不要滥用filters和实例变量；
7- 不要过度使用helpers，考虑HTML；
8- 合理配置日志；
9- 给你的Ruby GC打补丁；
10- 不鼓吹"premature optimization"，但是尽可能带有性能考虑来进行编码。

大家觉得对于RoR的应用，上述这些说到点子上了吗？感觉RoR在性能调优上我们积累的经验还不是很多，我有点担心，虽然上面有很多好的点子可以借鉴，文中提到的某些"强心剂"是否真的值得推广？尤其是针对数据库的那些"quick-and-dirty"的做法。

评论

7 楼 blackanger 2007-06-05  

sean_gao 写道

1- 在Ruby代码级别采用更优的方案；

貌似Ruby代码不需要优化吧，当然是在合理的基础上，几乎不影响性能。。。

6 楼 jerry 2007-03-04  

我感觉在数据库方面还是很有优化的必要的

5 楼 sean_gao 2007-02-11  

robbin 写道

sean_gao 写道

二位的回复说到我心坎里去了。

RoR的性能究竟如何，如果需要调优，怎么去调优，我想我们应该鼓励大家具体问题具体分析，拿出真金白银的数据出来，到底你的RoR应用有没有性能瓶颈，是什么地方出现瓶颈，然后对症下药去解决。

另：我隐隐约约觉得，RoR有一个潜在的问题，那就是Ruby的语法太灵活了，不容易形成大家公认的best practice，什么时候RoR圈子也能有一套相对稳定的blueprint，或者《Effective Ruby》、《Effective RoR》，可能大家的日子会好过很多吧。

http://robbin.iteye.com/blog/51595

这篇博客是我基于运营JavaEye网站的实践经验总结出来的RoR性能优化的文章，比你看的那篇文章要有实际意义的多。

Best practice或者说约定俗成的代码规范其实还是不难总结出来的。

谢谢robbin分享。

这里还有一篇blog，倒不是说它的观点有多少新意，后半段用电影《Star Wars》来比喻编程的段落很有趣，也很精彩：
http://blogs.tedneward.com/2007/01/15/The+Root+Of+All+Evil.aspx

4 楼 robbin 2007-02-11  

sean_gao 写道

二位的回复说到我心坎里去了。

RoR的性能究竟如何，如果需要调优，怎么去调优，我想我们应该鼓励大家具体问题具体分析，拿出真金白银的数据出来，到底你的RoR应用有没有性能瓶颈，是什么地方出现瓶颈，然后对症下药去解决。

另：我隐隐约约觉得，RoR有一个潜在的问题，那就是Ruby的语法太灵活了，不容易形成大家公认的best practice，什么时候RoR圈子也能有一套相对稳定的blueprint，或者《Effective Ruby》、《Effective RoR》，可能大家的日子会好过很多吧。

http://robbin.iteye.com/blog/51595

这篇博客是我基于运营JavaEye网站的实践经验总结出来的RoR性能优化的文章，比你看的那篇文章要有实际意义的多。

Best practice或者说约定俗成的代码规范其实还是不难总结出来的。

3 楼 sean_gao 2007-02-11  

二位的回复说到我心坎里去了。

RoR的性能究竟如何，如果需要调优，怎么去调优，我想我们应该鼓励大家具体问题具体分析，拿出真金白银的数据出来，到底你的RoR应用有没有性能瓶颈，是什么地方出现瓶颈，然后对症下药去解决。

另：我隐隐约约觉得，RoR有一个潜在的问题，那就是Ruby的语法太灵活了，不容易形成大家公认的best practice，什么时候RoR圈子也能有一套相对稳定的blueprint，或者《Effective Ruby》、《Effective RoR》，可能大家的日子会好过很多吧。

2 楼 gigix 2007-02-11  

应该在所有这些之前加上性能优化第一原则：不要优化。

1 楼 robbin 2007-02-11  

从大的方向上来说，建议都是合理的，但是具体的很多tricks不值得推荐，例如他推荐find_by_sql，不推荐find_by_name这样，这样兴许性能稍微有点好处，但是严重破坏代码可维护性和可读性。

没有必要特别关注rails的性能问题，只要编码合理，不会产生多大性能问题，即使访问量大导致的性能问题，也很容易通过添加硬件来解决。