19、Rails 应用部署、性能优化与扩展指南

最新推荐文章于 2025-12-01 19:45:15 发布

sql99

最新推荐文章于 2025-12-01 19:45:15 发布

阅读量4

点赞数

CC 4.0 BY-SA版权

分类专栏： Rails for PHP开发者入门文章标签： Rails部署 Mongrel集群性能优化

本文链接：https://blog.youkuaiyun.com/sql99/article/details/155488294

Rails for PHP开发者入门专栏收录该内容

26 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

Rails 应用部署、性能优化与扩展指南

1. 应用启动

1.1 环境准备

在启动应用之前，需要确保应用、数据库和环境都已准备就绪。可以通过修改配置文件 environment.rb 来设置应用的环境：

ENV['RAILS_ENV'] ||= 'production'

不过，这种方式需要修改应用的源代码，并非理想的解决方案。

1.2 启动单个 Mongrel 服务器

使用 Apache 和 Mongrel 进行部署，最基本的用法是部署单个 Mongrel 服务器实例。启动 Mongrel 服务器的命令如下：

current> mongrel_rails start -d -p 8000 -e production

这个命令会将 Mongrel 作为守护进程启动，监听 8000 端口，并使用生产环境启动应用。如果启动过程中遇到问题，可以查看 log/mongrel.log 文件进行排查。

1.3 配置 Apache 转发请求

为了让 Apache 转发所有请求到 Mongrel 服务器，需要在 Apache 中添加一个简单的虚拟主机条目。以下是一个示例配置文件 tucsonrails.org.conf ：

<VirtualHost *:80>
    ServerName tucsonrails.org
    ProxyPass / http://tucsonrails.org:8000/
    ProxyPassReverse / http://tucsonrails.org:8000
    ProxyPreserveHost on
</VirtualHost>

添加配置后，重启 Apache 服务器：

current> sudo apachectl restart

1.4 启动多个 Mongrel 服务器

随着应用的发展，可能需要运行多个 Mongrel 服务器来处理高流量。可以使用 Apache 的 mod_proxy_balancer 模块作为软件负载均衡器，将请求均匀分配到多个 Mongrel 实例上。

在启动多个 Mongrel 服务器之前，先停止之前启动的单个 Mongrel 服务器：

current> mongrel_rails stop

然后使用 mongrel_rails cluster::configure 命令配置 Mongrel 集群。以下是一个配置三个 Mongrel 服务器的示例：

current> mongrel_rails cluster::configure -e production \
-p 8000 -a 127.0.0.1 -N 3 -c /var/www/tucsonrails.org/current

这个命令会生成一个配置文件 config/mongrel_cluster.yml ，用于启动和停止 Mongrel 服务器。使用以下命令启动所有 Mongrel 服务器：

current> mongrel_rails cluster::start

1.5 配置 Apache 代理集群

使用多个 Mongrel 服务器时，需要在 Apache 配置目录中添加一个 proxy_cluster.conf 文件，指定负载均衡器将请求发送到哪些服务器。以下是一个示例配置文件 tucsonrails.org.proxy_cluster.conf ：

<Proxy balancer://mongrel_cluster>
    BalancerMember http://127.0.0.1:8000
    BalancerMember http://127.0.0.1:8001
    BalancerMember http://127.0.0.1:8002
</Proxy>

同时，还需要更新虚拟主机配置，以使用负载均衡器并利用 Apache 提供静态内容。以下是一个示例配置文件 tucsonrails.org.conf ：

<VirtualHost *:80>
    ServerName tucsonrails.org
    DocumentRoot /var/www/tucsonrails.org/public
    <Directory "/var/www/tucsonrails.org/public">
        Options FollowSymLinks
        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>
    RewriteEngine On
    # Rewrite index to check for static
    RewriteRule ^/$ /index.html [QSA]
    # Rewrite to check for Rails cached page
    RewriteRule ^([^.]+)$ $1.html [QSA]
    # Redirect all non-static requests to cluster
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]
    ErrorLog logs/tucsonrails.org_errors_log
    CustomLog logs/tucsonrails.org_log combined
</VirtualHost>

更新配置后，重启 Apache 服务器即可看到应用以 Mongrel 集群的方式部署。

1.6 应用启动流程总结

graph LR
    A[准备环境] --> B[启动单个 Mongrel 服务器]
    B --> C[配置 Apache 转发请求]
    C --> D[停止单个 Mongrel 服务器]
    D --> E[配置 Mongrel 集群]
    E --> F[启动多个 Mongrel 服务器]
    F --> G[配置 Apache 代理集群]
    G --> H[重启 Apache 服务器]

2. 性能优化

2.1 避免过早优化

在进行性能优化时，要牢记 Hoare’s Dictum：“过早优化是万恶之源”。不要过于关注一些微观的优化，如单引号和双引号的使用，而是要关注一些能显著提升应用响应速度的优化策略。

2.2 预加载数据

在部署应用之前，最后一次浏览应用时查看 development.log 文件，注意每个页面上运行的查询数量，寻找更多预加载数据的机会，以减少数据库的负载。

2.3 缓存页面

缓存策略对于提高应用性能非常重要。积极缓存页面可以减少应用执行的数据库查询，并减少 Rails 在视图中评估 Ruby 代码时的处理量。

2.4 压缩内容

通过压缩内容可以节省带宽并加快内容传递速度。使用 Apache 时，可以使用 mod_deflate 模块来压缩响应内容。在应用的虚拟主机条目中添加以下代码：

# Deflate static data
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

另一种选择是安装 Output Compression 插件，它使用 Ruby 来压缩输出内容，但不如 Apache 解决方案能压缩 JavaScript 和 CSS 文件。

2.5 减少 HTTP 请求

现代 Web 应用通常将 JavaScript 和 CSS 文件放在外部引用文件中，这会导致每个文件都需要向服务器发送一个 HTTP 请求，从而影响用户体验。可以通过将所有外部 JavaScript 和 CSS 文件合并为一个文件来解决这个问题。

使用 stylesheet_link_tag 助手时，可以传递 :all 作为第一个参数，并使用 :cache => true 选项来合并和缓存样式表：

<%= stylesheet_link_tag "screen", "more_stles",
:cache => "all" %>

同样，使用 javascript_include_tag 助手也可以实现 JavaScript 文件的合并和缓存：

<%= javascript_include_tag "prototype", "application",
:cache => "all" %>

默认情况下，Rails 只会在生产环境中合并和缓存这些文件，这样可以在开发环境中方便调试，在生产环境中提高性能。

2.6 资产托管

为了加快从服务器下载资源的速度，可以使用 Rails 的资产托管功能。在应用的 production.rb 文件中添加以下配置：

config.action_controller.asset_host = "http://assets%d.tucsonrails.org"

Rails 会创建四个不同的资产主机： asset0.tucsonrails.org 、 asset1.tucsonrails.org 、 asset2.tucsonrails.org 和 asset3.tucsonrails.org 。部署应用到生产环境时，Rails 会在这些不同的域名之间交替使用，从而让浏览器更快地下载资源。最后，需要为每个资产主机添加 DNS 别名，使其指向原始域名。

2.7 性能优化策略总结

优化策略	描述
预加载数据	查看日志，寻找预加载数据的机会，减少数据库负载
缓存页面	积极缓存页面，减少数据库查询和处理量
压缩内容	使用 `mod_deflate` 模块或 `Output Compression` 插件压缩内容
减少 HTTP 请求	合并和缓存 JavaScript 和 CSS 文件
资产托管	使用多个资产主机加快资源下载速度

3. 应用扩展

3.1 水平扩展的必要性

当网站流量增加到一定程度时，进行水平扩展比继续进行小的性能优化更经济实惠。水平扩展是指将流量分布到多个机器上，以提高系统的并发处理能力。

3.2 数据库扩展

Rails 应用通常将责任推给数据库，因此在扩展时，将数据库放在专用机器上是常见的做法。可以使用 Nic Williams 的 Magic Multi-Connections 插件来连接多个数据库。

3.3 应用服务器扩展

如果已经配置了 Apache 的代理负载均衡器，扩展应用服务器应该比较容易。可以通过修改代理集群配置文件，添加更多的 Mongrel 服务器实例，并将它们分布在多个服务器上。以下是一个示例配置文件 tucsonrails.org.proxy_cluster.conf ：

<Proxy balancer://mongrel_cluster>
    # cluster 1
    BalancerMember http://192.168.0.1:8000
    BalancerMember http://192.168.0.1:8001
    BalancerMember http://192.168.0.1:8002
    # cluster 2
    BalancerMember http://192.168.0.2:8000
    BalancerMember http://192.168.0.2:8001
    BalancerMember http://192.168.0.2:8002
    # cluster 3
    BalancerMember http://192.168.0.3:8000
    BalancerMember http://192.168.0.3:8001
    BalancerMember http://192.168.0.3:8002
</Proxy>

3.4 会话存储

在进行水平扩展时，需要注意会话存储的类型。确保会话数据不会保存到特定的服务器上，以免后续请求无法访问。默认的基于 cookie 的会话存储方式适用于这种扩展方式， ActiveRecord 存储方式也可以使用。

3.5 使用 Capistrano 进行部署

手动在多个服务器上部署应用不是一个好主意，而 Capistrano 可以让部署变得非常简单，只需要运行 cap deploy 命令即可。

3.6 应用扩展流程总结

graph LR
    A[确定扩展需求] --> B[数据库扩展]
    B --> C[应用服务器扩展]
    C --> D[配置会话存储]
    D --> E[使用 Capistrano 部署]

4. 总结与练习

4.1 总结

通过本文，我们学习了如何准备应用进行部署，掌握了将 Rails 应用部署到 Apache 下的负载均衡 Mongrel 集群的基础知识，了解了提高应用性能的策略以及如何进行负载均衡和扩展应用。

4.2 练习

以下是一些可以尝试的练习：
- 查看应用的日志，看看是否还有其他地方可以添加预加载数据的代码，以减少数据库的负载。
- 安装并设置 Exception Notification 插件，接收错误的电子邮件通知，并在生产应用中抛出一个异常，测试插件是否正常工作。
- 尝试将应用配置为运行在五个 Mongrel 实例上，而不是三个。
- 将 Rails 应用从开发平台部署到生产服务器，如果两个平台运行不同的操作系统，还可以获得额外的经验。

通过这些练习，可以进一步巩固所学的知识，并提高实际操作能力。

5. 深入理解性能优化策略

5.1 预加载数据的原理与实践

预加载数据是一种有效的减少数据库查询次数的方法。在 Rails 应用中，当一个页面需要关联多个模型的数据时，如果不进行预加载，每次访问关联数据都会触发一次数据库查询，这会导致性能下降。例如，一个博客应用中，一篇文章可能关联多个评论，当我们展示文章列表时，如果同时展示每篇文章的评论数量，不使用预加载的情况下，每篇文章都会触发一次查询评论数量的操作。

# 不使用预加载
articles = Article.all
articles.each do |article|
  puts article.comments.count
end

# 使用预加载
articles = Article.includes(:comments).all
articles.each do |article|
  puts article.comments.count
end

在上述代码中，使用 includes 方法可以一次性将文章和其关联的评论数据从数据库中查询出来，减少了数据库的交互次数，提高了性能。

5.2 缓存策略的选择与应用

缓存是提高应用性能的重要手段，Rails 提供了多种缓存方式，如页面缓存、动作缓存和片段缓存。
- 页面缓存 ：将整个页面的内容缓存起来，下次访问时直接从缓存中读取，避免了页面的重新渲染和数据库查询。例如，对于一些不经常变化的页面，如静态页面、文章详情页等，可以使用页面缓存。

class ArticlesController < ApplicationController
  caches_page :show
end

动作缓存 ：缓存控制器动作的输出，适用于一些需要进行身份验证或权限检查的页面。

class UsersController < ApplicationController
  caches_action :dashboard
end

片段缓存 ：缓存页面中的某个部分，适用于页面中部分内容变化频繁，而其他部分相对稳定的情况。

<% cache do %>
  <div>
    <!-- 缓存的内容 -->
  </div>
<% end %>

5.3 压缩内容的效果分析

使用 mod_deflate 模块或 Output Compression 插件压缩内容可以显著减少传输的数据量，提高页面的加载速度。例如，一个未压缩的 HTML 文件大小为 100KB，经过压缩后可能只有 20KB，这意味着用户在下载页面时可以节省大量的时间和流量。

5.4 减少 HTTP 请求的实际应用

合并和缓存 JavaScript 和 CSS 文件可以减少 HTTP 请求的数量，提高页面的加载性能。在开发过程中，我们可以将多个 CSS 文件和 JavaScript 文件分别合并成一个文件，减少浏览器与服务器之间的交互次数。例如，将多个 CSS 文件合并成 all.css ，将多个 JavaScript 文件合并成 all.js 。

# 合并 CSS 文件
<%= stylesheet_link_tag :all, cache: 'all' %>

# 合并 JavaScript 文件
<%= javascript_include_tag :all, cache: 'all' %>

5.5 资产托管的优势与配置

使用资产托管可以增加从多个主机下载资源的机会，提高资源的下载速度。当浏览器同时从多个不同的主机下载资源时，可以突破浏览器对单个主机的并发连接限制。在配置资产托管时，需要在 production.rb 文件中设置 asset_host 。

config.action_controller.asset_host = "http://assets%d.tucsonrails.org"

同时，需要为每个资产主机添加 DNS 别名，确保它们指向原始域名。

6. 应用扩展的注意事项

6.1 数据库扩展的挑战与解决方案

将数据库放在专用机器上可以提高数据库的性能，但也会带来一些挑战，如数据同步、网络延迟等。为了解决这些问题，可以使用数据库复制技术，将主数据库的数据复制到多个从数据库上，实现读写分离。例如，使用 MySQL 的主从复制功能，将读操作分发到从数据库上，减轻主数据库的负担。

6.2 应用服务器扩展的负载均衡算法

在使用 Apache 的 mod_proxy_balancer 模块进行负载均衡时，有多种负载均衡算法可供选择，如轮询、加权轮询、IP 哈希等。
- 轮询：将请求依次分配到各个服务器上，适用于服务器性能相近的情况。
- 加权轮询 ：根据服务器的性能为每个服务器分配不同的权重，性能好的服务器分配更多的请求。
- IP 哈希 ：根据客户端的 IP 地址将请求分配到固定的服务器上，适用于需要保持会话一致性的情况。

6.3 会话存储的安全性与可靠性

在选择会话存储方式时，除了要考虑是否适用于水平扩展，还要考虑会话数据的安全性和可靠性。基于 cookie 的会话存储方式将会话数据存储在客户端的 cookie 中，存在一定的安全风险，如 cookie 被篡改、窃取等。可以使用加密的 cookie 或 ActiveRecord 存储方式来提高会话数据的安全性。