写点什么

关注部署:谈 Rails 应用的最后一公里

  • 2008-01-15
  • 本文字数:1912 字

    阅读完需:约 6 分钟

基于 Rails 框架应用开发的普及,在为用户带来众多创造性应用的同时,也赋予了开发者令人兴奋的高效与快捷体验。使用 Rails 开发 Web 应用的最后一个步骤,是要把 Ruby 代码从开发测试环境中迁移到实际生产模式之下。相比于开发过程来说,应用的部署并非易事。如何保证部署后站点的稳定和健壮性,并且可以从容应对大规模的并发访问,每一位富有经验的开发者或许都有自己的一套途径,就此,InfoQ 中文站汇总了近期 Rails 部署问题的各方面观点,为您提供参考。

早在 Rails 应用普及之初,就时常会听见针对 Rails 部署问题的抱怨。对于 PHP,一直以来都是以成熟的 LAMP 模式进行部署,讨论主要是集中在如何有效的进行服务器规模的拓展等等。而 Rails 方面则是没有统一的规则,Web 服务器的组合方式和部署工具也都有各自的特色,应用的部署对开发新手来说,是个常会产生困惑的问题,在题为“我不喜欢 RoR 的原因”的帖子中,一位开发者提到:

RoR 无疑是目前最具生产效率的开发框架之一,实现同样的应用,确使得开发时间缩减到原先的一半。但令我感到困扰的是,RoR 对于开发者的确具有吸引力,但客户却并不这么认为。比方说,Rails 应用的部署方式非常复杂,客户并不熟悉如何将开发好的应用部署在自己的服务器上,并且他们不喜欢使用命令行和脚本来操作 Rails 应用。

的确,相比 PHP 应用 LAMP 模式的部署,Rails 的可选方案非常多。保持站点的稳定性和健壮性,所涉及的不仅仅是 Rails 或 Ruby 开发相关的技术,还有很多因素来自于 Web 服务器和应用服务器的选择与搭配。Rails 部署常见的架构中,前端服务器加多个进程处理的方式如 Fastcgi,Mongrel 的选择以及与 Web 服务器的搭配使用,往往会给用户造成困扰。在《应用 Rails 进行敏捷 Web 开发》一书中,对于 Rails 的部署过程也作了简单的描述,但是所提供的部署方式并不十分合适于大规模网站的并发访问。论坛里的讨论中,常会针对于 Lighttpd+FastCGI、Nginx+Mongrel、Apache+FastCGI 等不同的搭配模式展开讨论。对于 Mongrel 服务器,Robbin 在文章“ RoR 部署方案深度剖析”中评价道:

我们假设使用服务器端程序控制带权限的文件下载,某用户下载的是一个 100MB 的文件,该用户使用了多线程下载工具,他开了 10 个线程并发下载,那么每个线程 Mongrel 在响应之后,都会把整个文件读入到内存的 StringIO 对象当中,所以总共会创建出来 10 个 StringIO 对象保存 10 份文件内 容,所以 Mongrel 的内存会一下暴涨到 1GB 以上。而且最可怕的是,即使当用户下载结束以后,Mongrel 的内存都不会迅速回落,而是一直保持如此 高的内存占用,这是因为 Ruby 的 GC 机制不好,不能够及时进行垃圾回收。

对此,robinlu 根据自己的 Rails 部署经验写道

Mongrel 处理 rails request 和静态文件使用的是不同的 handler。处理静态文件用的是 DirHandler,DirHandler 没有通过调用 response 的 start 方法使用到 StringIO, 而是直接调用了 response 的 send_file 方法,直接 write socket。验证过程非常简单,自己起一个 mongrel,在 public 下放一个 100M 的文件,通过浏览器下载一下。在我的 mac 上, 本来是 76M 的 mongrel,在下载结束后是 74M,下载过程中也一直小于 80M,最低到过 68M。无论是过程中还是结束后,都没有出现占用内存暴涨的现象。

的确,针对 Rails 部署的 Web 服务器与应用服务器的搭配方案,会令客户面对众多的选择,并且 JVM 之上的 JRuby 以及微软.Net 平台上的 Ruby 运行环境,都可能会使得 Rails 的部署呈现多元化发展的趋势。Robbin 在文章中对于 JavaEye 站点部署方案的选择做出了如下的总结:

Lighttpd+FastCGI 是性能最佳,服务器资源消耗最少的 RoR 部署方案,事实上目前 RoR 网站部署使用最多最流行的也是 Lighttpd+FastCGI 方式,而 JavaEye 网站,自然也是这种方式的部署。因此我们可以对各种方案进行一个性能优劣的排队,即 Lighttpd+FastCGI 是性能最佳方案,而 Apache+FastCGI 是性能最差方案。

从设计架构上来说,对静态文件的处理应尽量由 Web 服务器前端处理,避免多线程下载对 cpu 和带宽的影响。搭配的方式有很多,方案选择的优劣也不能一概而论,需要根据具体情况做出最合适自身的选择。在 InfoQ 中文站之前的一篇新闻“与时俱进的轻量级Web 服务器”中,也解释了Lighttpd+FastCGI 成为目前Rails 网站优秀部署方案的原因。对于各种选择和经验之谈,毕竟是仁者见仁、智者见智的事情,但无疑,关注小型轻量级服务器的发展,及其自动化部署工具和一站式集成化生产环境,都会给应用的部署上线带来有益的帮助。

关于应用服务器部署的更多信息,可以在InfoQ 中文站的部署应用服务器相关主题,以及 ChinaonRails 服务器架构讨论区中详细了解。

2008-01-15 07:093223
用户头像

发布了 74 篇内容, 共 13.8 次阅读, 收获喜欢 3 次。

关注

评论

发布
暂无评论
发现更多内容

《 黑神话 · 悟空》视觉震撼背后的技术力量:如何用云桌面加速 CG 视觉创作 !

Finovy Cloud

游戏开发 游戏 黑神话悟空 黑神话

MobPush扩展业务功能设置

MobTech袤博科技

开发者 产品动态

RPA机器人流程自动化的5个必知关键点

八爪鱼采集器︱RPA机器人

RPA 自动化 RPAxAI

RPA技术:基本概念和应用场景的全面指南

八爪鱼采集器︱RPA机器人

RPA 自动化 RPAxAI

聊聊TiCDC

TiDB 社区干货传送门

7.x 实践

杭州百腾教育科技 TiDB 6.5 to 7.5 升级记录

TiDB 社区干货传送门

版本升级 7.x 实践

脉讯在线:核心TiDB 从 5.4 升级到 7.1 集群 CDC 性能翻倍

TiDB 社区干货传送门

实践案例 版本升级 性能测评

亿玛科技:TiDB 6.1.5 升级到 7.5.1 经验分享

TiDB 社区干货传送门

版本升级 7.x 实践

从Oracle到TiDB,全链路数据迁移平台核心能力和杭州银行迁移实践

TiDB 社区干货传送门

TiKV Raft 快照全流程丨TiKV 源码解读(二十二)

TiDB 社区干货传送门

高性能桌面管理系统助力实现国产化生态!

上海锐起科技

离奇问题,网络故障恢复后,无法重连到数据库?

中原银行

Java TCP 容器云 HikariCP 网络故障

生成式AI已融入你的生活和工作了吗?

天津汇柏科技有限公司

人工智能 生成式AI 生成式 AI 应用

国家下达绿色转型目标!电子签章领域未来的发展趋势如何?

Geek_2a38d5

利用API返回值实现商品信息的自动化更新

技术冰糖葫芦

API Explorer API 测试 API 策略 pinduoduo API

如何提高研发效能?思码逸 & 信通院告诉你

思码逸研发效能

团队管理 DevOps #研发效能

MobPush推送查询

MobTech袤博科技

Java 开发者 产品动态

作业帮 & TiDB 7.5.x 使用经验

TiDB 社区干货传送门

7.x 实践

TiDB 扩缩容原理及常见问题

TiDB 社区干货传送门

管理与运维 故障排查/诊断 扩/缩容 TiKV 底层架构 7.x 实践

SDN网络技术在云计算中的应用

天翼云开发者社区

SDN网络

金融企业区域集中库的设计构想和测试验证

TiDB 社区干货传送门

Titan 引擎:通过从 LSM-Tree 中分离大值,实现 6 倍的写入性能的提升

TiDB 社区干货传送门

DPDK简介和原理

天翼云开发者社区

DPDK

国产RPA软件的优势:企业数字化转型中的关键作用详解

八爪鱼采集器︱RPA机器人

RPA 自动化 RPAxAI

分布式数据库系统环境的“无感”升级

TiDB 社区干货传送门

关于 TiDB 升级后结果不一致问题

TiDB 社区干货传送门

管理与运维 故障排查/诊断 新版本/特性解读 应用适配 6.x 实践

火山引擎VeDI实验平台助推企业量化决策能力升级

字节跳动数据平台

大数据 A/B 测试 对比实验 数字化增长

2024即刻职达人才生态合作大会于珠海横琴成功召开,共话数智时代人力资源新趋势

新消费日报

RPA实施的四大阶段:一步步的详细指南

八爪鱼采集器︱RPA机器人

RPA 自动化 机器人 RPAxAI

【喜讯】数业智能当选“广东省卫生信息网络协会”理事单位

心大陆多智能体

智能体 AI大模型 心理健康 数字心理

关注部署:谈Rails应用的最后一公里_Ruby_高昂_InfoQ精选文章