优化Ruby on Rails性能：内存与GC策略

201 浏览量更新于2024-08-31 收藏 129KB PDF 举报

"文章主要探讨了优化Ruby on Rails性能的方法，重点关注了避免内存密集型应用和垃圾回收（GC）的问题，以及如何通过扩容、缓存和代码优化来提升Rails应用的运行速度。" 在Ruby on Rails开发中，性能优化是一个至关重要的环节，尤其是在面临大量用户请求或数据处理时。本文提出的优化策略主要围绕两个核心问题：选择合适的技术栈和管理内存消耗。首先，作者指出，Rails框架虽然强大且易用，但并不适合所有类型的项目。如果在不适合使用Ruby和Rails的地方强行使用它们，可能会导致性能下降。例如，对于大数据处理，数据库查询效率更高，应优先考虑使用专门的数据库技术；而对于统计分析，R语言可能更为合适。其次，内存管理是Rails应用性能瓶颈的主要来源。由于Ruby的垃圾回收机制（GC）需要处理大量内存分配，内存消耗过大将导致GC频繁运行，从而严重影响应用性能。因此，优化内存使用是提升Rails应用速度的关键。作者建议监控内存使用情况，合理设计数据结构，避免无谓的对象创建，以及使用更轻量级的数据存储方式如JSON或YAML代替ActiveRecord模型。为了使Rails应用运行更快，作者提出了三种策略： 1. 扩容：通过增加服务器实例来分摊负载，这在云平台如Heroku上很容易实现。然而，扩容不是万能的，特别是对于响应时间要求极高的场景，单纯增加实例并不能解决问题，还可能导致成本快速增加。 2. 缓存：Rails提供了多种缓存机制，如块缓存、页面缓存和动作缓存等，可以有效减少数据库查询次数，提升响应速度。然而，过度依赖缓存可能会引入新的复杂性，且并不能解决根本的代码效率问题。 3. 代码优化：这是提升性能的最根本途径。通过对代码进行重构，减少不必要的计算，优化数据库查询，使用更高效的算法，以及遵循Ruby的最佳实践，可以显著提升应用性能。在实践中，开发者应结合这些策略，并根据应用的具体需求和工作负载情况，灵活运用和调整优化措施，以实现最佳的性能表现。同时，持续监控和测试也是确保优化效果的关键步骤。

对优化对优化Ruby on Rails性能的一些办法的探究性能的一些办法的探究

主要介绍了对优化Ruby on Rails性能的一些办法的一些探究,包括避免内存密集型的应用和GC等相关问题的探讨,需要的朋友可以参

考下

1.导致你的导致你的 Rails 应用变慢无非以下两个原因：应用变慢无非以下两个原因：

1. 在不应该将 Ruby and Rails 作为首选的地方使用 Ruby and Rails。（用 Ruby and Rails 做了不擅长做的工作）

2. 过度的消耗内存导致需要利用大量的时间进行垃圾回收。

Rails 是个令人愉快的框架，而且 Ruby 也是一个简洁而优雅的语言。但是如果它被滥用，那会相当的影响性能。有很多工作并不适合用 Ruby and

Rails，你最好使用其它的工具，比如，数据库在大数据处理上优势明显，R 语言特别适合做统计学相关的工作。

内存问题是导致诸多 Ruby 应用变慢的首要原因。Rails 性能优化的 80-20 法则是这样的：80% 的提速是源自于对内存的优化，剩下的 20% 属于其

它因素。为什么内存消耗如此重要呢？因为你分配的内存越多，Ruby GC（Ruby 的垃圾回收机制）需要做的工作也就越多。Rails 就已经占用了很大

的内存了，而且平均每个应用刚刚启动后都要占用将近 100M 的内存。如果你不注意内存的控制，你的程序内存增长超过 1G 是很有可能的。需要回

收这么多的内存，难怪程序执行的大部分时间都被 GC 占用了。

2 我们如何使一个我们如何使一个 Rails 应用运行更快应用运行更快?

有三种方法可以让你的应用更快：扩容、缓存和代码优化。

扩容在如今很容易实现。Heroku 基本上就是为你做这个的，而 Hirefire 则让这一过程更加的自动化。其它的托管环境提供了类似的解决方案。总

之，可以的话你用它就是了。但是请牢记扩容并不是一颗改善性能的银弹。如果你的应用只需在 5 分钟内响应一个请求，扩容就没有什么用。还有就

是用 Heroku + Hirefire 几乎很容易导致你的银行账户透支。我已经见识过 Hirefire 把我一个应用的扩容至 36 个实体，让我为此支付了 $3100。我立

马就手动吧实例减容到了 2 个, 并且对代码进行了优化.

Rails 缓存也很容易实施。Rails 4 中的块缓存非常不错。Rails 文档是有关缓存知识的优秀资料。不过同扩容相比，缓存并不能成为性能问题的终极

解决方案。如果你的代码无法理想的运行，那么你将发现自己会把越来越多的资源耗费在缓存上，直到缓存再也不能带来速度的提升。

让你的 Rails 应用更快的唯一可靠的方式就是代码优化。在 Rails 的场景中这就是内存优化。而理所当然的是，如果你接受了我的建议，并且避免把

Rails 用于它的设计能力范围之外，你就会有更少的代码要优化。

2.1 避免内存密集型避免内存密集型Rails特性特性

Rails 一些特性花费很多内存导致额外的垃圾收集。列表如下。

2.1.1 序列化程序序列化程序

序列化程序是从数据库读取的字符串表现为 Ruby 数据类型的实用方法。

class Smth < ActiveRecord::Base

serialize :data, JSON

end

Smth.find(...).data

Smth.find(...).data = { ... }

它要消耗更多的内存去有效的序列化，你自己看：

class Smth < ActiveRecord::Base

def data

JSON.parse(read_attribute(:data))

end

def data=(value)

write_attribute(:data, value.to_json)

end

这将只要 2 倍的内存开销。有些人，包括我自己，看到 Rails 的 JSON 序列化程序内存泄漏，大约每个请求 10% 的数据量。我不明白这背后的原

因。我也不知道是否有一个可复制的情况。如果你有经验，或者知道怎么减少内存，请告诉我。

2.1.2 活动记录活动记录

很容易与 ActiveRecord 操纵数据。但是 ActiveRecord 本质是包装了你的数据。如果你有 1g 的表数据，ActiveRecord 表示将要花费 2g，在某些情况

下更多。是的，90% 的情况，你获得了额外的便利。但是有的时候你并不需要，比如，批量更新可以减少 ActiveRecord 开销。下面的代码，即不会

实例化任何模型，也不会运行验证和回调。

Book.where('title LIKE ?', '%Rails%').update_all(author: 'David')

后面的场景它只是执行 SQL 更新语句。

update books

set author = 'David'

where title LIKE '%Rails%'

Another example is iteration over a large dataset. Sometimes you need only the data. No typecasting, no updates. This snippet just runs the query and avoids ActiveRecord altogether:

result = ActiveRecord::Base.execute 'select * from books'

result.each do |row|

# do something with row.values_at('col1', 'col2')

end

2.1.3 字符串回调字符串回调

Rails 回调像之前/之后的保存，之前/之后的动作，以及大量的使用。但是你写的这种方式可能影响你的性能。这里有 3 种方式你可以写，比如：在保

存之前回调：

before_save :update_status

before_save do |model|

model.update_status

下载后可阅读完整内容，剩余3页未读，立即下载

weixin_38638004

粉丝: 3
资源: 900

优化Ruby on Rails性能：内存与GC策略

rormatrixru.github.io:Ruby on Rails 开发人员能力矩阵

深入探究Ruby on Rails：MVC模式与模型层

探究Ruby on Rails中的国际化与本地化技术

Ruby Hacking Guide

Ruby语言中文教程

[Web开发敏捷之道--应用rails源代码][5]txt

深入探究Rails3中的Sidekiq消息队列系统

深入理解Ruby：Ruby Under a Microscope原著PDF

计算机语言发展史与现状探究

Vim 插件开发指南：vim-rubymotion 探究

最新资源