Ruby on Rails 性能优化的 10 大建议

Ruby on [b]Rails 性能优化的 10 大建议

[/b]
Ruby On Rails 项目的性能受很多因素的影响，特别是部署服务器的配置。然而程序代码还 是会带来很大不同甚至是决定了你的站点响应速度的快慢。这篇短文介绍了一些关于在 Rails 中对提升性能有很大好处的编码经验，不讨论复杂的关于优化服务器配置方面的内容。 1、优化你的 Ruby 代码。这一点说起来显而易见，但是 Rails 程序在运行时本质上都是 Ruby 代码，所以要确信你的代码从 Ruby 的角度来说是有高效的。对你的代码进行一下回顾，看 看是否需要做一些重构，要不断进行性能和算法效率的考虑。 当然性能测试工具对检测较慢 代码是非常有用的，不过下面所列的几项是通常要考虑到的（其中有几项可能对你们来说 已经是常识了）。 1> 如果有可能的代码或者插件，就不必自己再去写了。 2> 在需要转换和处理大文本的时候，用正则表达式要好过用循环判断。 3> 处理 XML 文档用 Libxml 库，性能优于 REXML. 4> 有时你需要为了速度尽量减少一些优雅抽象的编码方式 (比如 define_method 和 yield 是比 较耗资源的。) 5> 解决循环语句缓慢问题的最好办法，就是只要有可能就去掉它们。有时候在一切情况下 你是可以通过重构代码来避免使用循环的。 6> if/unless 语句应尽量简单化并且减少这样的语句，相应的记住 ||= 操作符是你编码时的 朋友。 7> Hash 是昂贵的数据结构。要是你需要不断重复调用一个值可以将其存在一个局部变量里。 更普遍来说，好的方式是把经常要访问到的数据存在变量里(局部，实例或者是类变量)。 2.缓存是好的：缓存能够大幅度地为应用程序加速。可以分几个方面来做： 1> 使用 acts_as_cached 或者 cached_model 组建来缓存模型对象。 2> 使用 MemCacheStore 作为 Session 容器。 3> 通过片段缓存来保存页面(可参考 extended_fragment_cache)。 3、 充分发挥数据库的威力是铁律。 不要拒绝使用数据库提供的很多很酷的功能，即使它们不 ActiveRecord 来实现的。例如，定义一些存储过程和函 是由 Rails 直接提供或者是通过 数，就可以通过驱动来使用它们直接进行数据库的相关操作，这 要好过于在 ActiveRecord 中定义的高层次的方法。这样会大大提高在 Rails 程序中操作数据的性能。 4、 Finders(查找)是超级有用的但是要小心使用。 finders 使用起来是让人愉快的，让你能容易 地写出可读性高的代码，并 且还不需要有深入的 SQL 知识。 但是易用友好的高层次抽象 化就带来了更多的消耗，在使用时可依据以下几个主要的原 则： 1> 只获取需要的数据。 选择语句中读取一些不是真正需要的数据会浪费处理时间。 在使用 各种查询时要确定使用了正 确的参数，在:select 参数中指定真正要读取的字段，如果仅仅需要在数据集中读取一定数 量的记录，可以适当地加以 限制(使用:limit 和:offset 属性). 2> 不要让过多的查询把数据库挂掉了，要使用 include 属性来做关联查询。 # 这将只产生一个查询, # rather than Post.count + 1 queries

for post in Post.find(:all, :include => [ :author, :comments ]) # Do something with post end 3> 避免使用类似 MyModel.find_by_*这样的动态查询。使用 User.find_by_username 这样的 语句可读性高并且容易，但是 也带来多一些的消耗。事实上，ActiveRecord 是在 method_missing 中动态生成这些方法的， 所以会比较慢。实际上被定 义和调用的方法，还有在模型类中做的属性映射，最终都 会转化成一个查询语句然后发送给数据库。所以直接使用 MyModel.find_by_sql 或者 MyModel.find 会带来更高的效率。 4> 无论什么时候最优化的 SQL 查询都是使用 MyModel.find_by_sql。不言自明的，即使最 find_by_sql 要比 find 更有效率(因为无需将赋给方法的 终的查询语句是一样的，使用 各种属性参数转换成 SQL 语句)。如果你正在构建一个跨平台使 用的插件，那需要确认所有的 SQL 能够在 Rails 支持的各种数据库上正确执行，或者就要 用 find 方法来替换。一般来说， 用 find 方法有更好的可读性和可维护性，所以在开始用 find_by_sql 对应用做重构前，需 要做些评测和区分哪些查询 较慢需要手工做优化。 5、将一组操作放在一个事务里：ActiveRecord 会将创建和更新记录的操作封装在一个事务 里，多个插入操作会产生多个 事务(每个插入操作一个事务)。把多个插入操作放在一个事务中处理会提升速度。 原代码： my_collection.each do |q| Quote.create({:phrase => q}) end 优化后: Quote.transaction do my_collection.each do |q| Quote.create({:phrase => q}) end end 或者让任何一次插入操作失败都回滚，这样写： Quote.transaction do my_collection.each do |q| quote = Quote.new({:phrase => q}) quote.save! end end 6、 控制好你的控制器：过滤器是昂贵的，不要滥用它们。 并且，也不用过度使用实例变量， . 如果不是被视图所需要的 7、在视图中多使用 HTML.在视图模板里不要过多使用 helper，每次用 helper 构建页面都会 带来额外的步骤。我们是不是

真的需要使用 helper 的方法来生成一个链接的 html，或者是一个文本框或者表单呢？ (这 会让对 ruby 不熟悉的页面设 计者开心的。) 8、 日志记录：对应用进行配置只记录真正有用的信息。 日志是消耗很大的操作，配置不当的 日志记录级别(例如 Logger::DEBUG)会影响产品模式下应用的性能。 9、 GC 补丁：对，不是一个真正的代码发布版本，而是针对 Ruby 的垃圾回收做一个高效 打 的优化补丁，这将较大地提升 Rails 的速度。 10、最后一条：我不提倡过早地做性能优化，如果可能，先对这些优化原则有个意识 (但不 要做得过度).