Ruby on Rails真实案例三则

本文主要是介绍Ruby on Rails真实案例三则，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

（正如前一篇文章里所许诺的，这里将列出三个采用RoR开发的真实案例。以下内容出自《应用Rails进行敏捷Web开发》一书第22章。）

22.7 案例分析：每天运行的Rails

要证明Rails的伸缩性，最好的办法莫过于考察一个确实有效伸缩的应用程序。在这一节中，我们将考察三个真实应用遇到的性能问题，以及它们如何解决这些问题。

37signals开发的Basecamp（www.basecamphq.com）

Rails就诞生于Basecamp项目。这是一个基于web的项目管理工具，它的用户需要每月付款。Basecamp服务器为成千上万的用户提供项目管理所需的功能服务。

在为Basecamp进行性能优化时，最大的难题在于很难使用缓存：每个人都来自不同的公司、有着不同的权限，因此看到的数据也各有不同。（不过从好的方面来说，只有那些拥有注册账号的人才能访问Basecamp，所以不用担心它会被Slashdot介绍而带来一大堆未授权的用户。）

Basecamp每天处理大约40万个动态请求（从看到登录页面开始算起，直到浏览项目记录板，所有的请求都包含在内）。在无法做任何缓存的情况下，这个负载量是相当可观的。目前有两台web/应用服务器来处理这些请求，每台服务器都有两个至强2.4GHz CPU和2GB内存，运行15个FastCGI进程和50-100个Apache 1.3.x进程。服务器的负荷比通常在0.5到1.5之间。

MySQL数据库服务器是独立的，但37signals的另外两个应用程序（Ta-da List和Backpack）也使用这个数据库。数据库里的记录数在十万级别上，最大的一张表有大约50万条记录。虽然要为三个应用程序提供服务，但数据库服务器的负荷比通常在0.1到0.3之间——数据库不是Basecamp的瓶颈所在，这是一个好消息。如果当前的两台服务器不堪重负，只要再加上新的服务器就可以解决问题，而且我们也确实这样做了。

Robot Co-op开发的43 Things（www.43things.com）

43 Things是一个用于“追踪人生目标”的站点。你可以在这里写上你的目标，譬如“我要学日语”，围绕着这个目标撰写blog，并阅读别的有同样目标的人在干什么。这个应用程序的一部分需要身份认证；更多的部分则是公开的，允许未经授权的用户访问。公开内容访问量常有剧烈的变化；不过还好可以对它们进行缓存。

缓存的存储策略采用了memcached——为了改善性能，这个网站大量使用了memcached。由于将用户的session数据保存在memcached中，任何一台服务器都可以在任何时候处理来自任何用户的请求，而不需要任何session同步措施。对于开销较大的数据库查询，其结果也以ActionRecord对象的形式被序列化到memcached中，并打上适当的时间戳。

上线三个月之后，43 Things每天处理约20万个动态请求。它使用了两台web/应用服务器，以及一台专用的数据库服务器，三台机器都有两个3GHz的至强CPU和2GB内存。两台web/应用服务器上分别运行着Apache 1.3.x服务器和25个FastCGI进程。服务器负荷比很少超过0.3，CPU空闲时间经常在80%左右。

抵押处理引擎（www.rapidreporting.com）

Rapid Reporting将他们的“身份及收入验证引擎”运行在Rails系统上。美国1000强的抵押担保商有80%都使用这套引擎，每月处理2百万次抵押申请交易。

一开始，Rapid Reporting希望检验Rails是否能够胜任，因此他们从10台集群机器向一个应用程序进行压力测试，每秒发起3千次请求。真实的应用程序大概需要每秒处理300次请求，并执行一系列的业务逻辑。此外，处理抵押业务必须遵循格莱姆-布里勒法规（GLBA），因此很多地方都需要检查授权许可、生成查账索引。

应用程序使用PostgreSQL作为数据库，lighttpd作为web服务器，每台应用服务器运行大约10个FastCGI进程，在一台虚拟服务器上用IP隧道技术实现负载均衡（参见http://www.linuxvirtualserver.org/VS-IPTunneling.html）。使用这种部署方式，就可以随时增减FastCGI进程，而不必重启web服务器。由此又可以实现进程管理的自动化：用一个守护进程监视负载情况，当负载达到峰值时分配更多的FastCGI进程。