Ruby on Rails的服务器选项 [英] Ruby on Rails Server options

问题描述

建立一个开发服务器为我的Ruby on Rails应用程序的整个问题混淆了我。还有的WEBrick，杂种，客运，阿帕奇，Nginx的，还有更多我相信，我真的不明白他们扮演的不同角色。

我开始使用的WEBrick，现在我用杂种的发展。这些服务器单机，还是他们坐在Apache的面前？

我看了一下乘客，我真的不明白它是什么，该网站说，使得Ruby的web应用程序的部署清风，它取代杂种？是像Capistrano的，其中也部署Web应用程序？

铭记我想测试SSL，而且我相信不是由杂种支持，什么是最好的开发服务器设置？

解决方案

词部署可以根据上下文两方面的含义。你也混淆阿帕奇/ Nginx的角色与其他成分的作用<​​/ P>

历史注：这篇文章最初写于2010年11月6日，当Ruby的应用服务器的生态系统是有限的。我已经更新了这篇文章2013年3月15日，在生态系统中的所有最新的更新。

免责声明：我的Phusion客运，应用服务器之一的作者之一。

阿帕奇VS Nginx的

他们都是Web服务器。他们可以提供静态文件，但 - 用正确的模块 - 也可以提供动态Web应用程序如那些用PHP编写的。 Apache是​​更受欢迎，有更多的功能，Nginx的体积更小，速度更快，具有较小的特点。

无论是阿帕奇也不Nginx的可以成为Ruby的web应用程序外的开箱，要做到这一点需要结合使用Apache / Nginx的具有某种附加的，后面介绍。

Apache和Nginx的也可以充当反向代理，这意味着它们可以采取一个传入的HTTP请求，并转发给其他服务器，这也讲的HTTP。当该服务器与HTTP响应进行响应，阿帕奇/ Nginx的将转发响应返回给客户端;您将学习以后为什么这是相关的。

杂种狗等生产应用服务器VS的WEBrick

Mongrel是一个Ruby应用程序服务器：具体而言，这意味着Mongrel是一个应用程序，其中：

1. 加载你的Ruby应用程序自己的进程空间内。


2. ，设置一个TCP套接字，允许它与外界（例如，因特网）进行通信。
   杂种侦听此套接字上的HTTP请求，并请求数据传递到Ruby的Web应用程序。


3. 的Ruby的web应用程序，然后返回一个对象，它描述了HTTP响应应该是什么样子，以及杂种需要将其转换为实际的HTTP响应（实际字节）的照顾，并通过套接字送了回去。

不过杂种是相当过时，现在它不再保留。较新的替代应用服务器：

• 的Phusion客运


• 麒麟


• 薄


• 彪马


• 特立尼达（仅JRuby的）


• TorqueBox（仅JRuby的）

我会提到他们，描述他们彼此和杂种的区别。

的WEBrick做同样的事情的杂种，不过区别是：

• 的WEBrick不适合生产，不像其他一切我前面提到的。 WEBrick是使用Ruby中完全写。杂种（以及大多数其他的Ruby应用服务器）是部分Ruby和C部分（大部分红宝石），但它的HTTP分析器用C语言编写的表现。


• 的WEBrick是慢，不太可靠。它有一些已知的内存泄漏和一些已知的HTTP分析问题。


• 的WEBrick通常只在开发过程中，因为使用WEBrick默认情况下包含在Ruby中作为默认的服务器。杂种和其他应用服务器需要单独安装。它不推荐使用的WEBrick在生产环境中，但由于某些原因的Heroku选择的WEBrick作为其默认服务器。他们之前用薄，所以我不知道为什么他们转向的WEBrick。

的应用服务器和世界

目前所有的Ruby应用服务器的HTTP说话，但有些应用服务器可以直接接触到端口80上互联网，而其他人可能不会。

• 可以直接暴露在互联网上的应用服务器：Phusion的乘客，彩虹


• 可能不直接暴露在Internet应用服务器：杂种狗，独角兽，薄，彪马。这些应用程序服务器必须把后面的反向代理Web服务器的像Apache和Nginx的。


• 我不知道有足够的了解特里尼达和TorqueBox，所以我省略了他们。

为什么要一些应用服务器后面的反向代理放？

• 某些应用服务器只能同时处理1的要求，每个进程。如果要同时处理2个请求，你需要运行多个应用程序服务器实例，每服相同的Ruby应用程序。这套应用程序服务器进程被称为的应用程序服务器集群的（因此得名杂种集群，集群薄等）。然后您必须设置Apache或Nginx的反向代理到此集群。阿帕奇/ Nginx的将采取集群（章节I / O并发模型更多内容）分发的实例之间的请求照顾。


• Web服务器可以缓冲请求和响应，保护从慢客应用程序服务器 - HTTP不很快发送或接收数据的客户端。你不希望你的应用服务器做什么在等待客户端发送完整的请求或接收完整的响应，因为在这段时间内应用服务器可能无法做别的。 Apache和Nginx的是在同一时间，因为他们要么多线程或事件触发做的很多事情非常好。


• 大多数应用服务器可以提供静态文件，但没有它特别好。 Apache和Nginx的可以更快地做到这一点。


• 人们通常设置Apache / Nginx的直接服务静态文件，但不以静态文件对应的应用服务器转发请求，这是良好的安全习惯。 Apache和Nginx的是非常成熟的，可以屏蔽来自（可能是恶意）应用服务器损坏请求。

为什么一些应用服务器直接暴露在Internet中？

• 的Phusion乘客是从所有其他应用服务器一个非常不同的野兽。它的一个独特功能是它集成到Web服务器。


• 彩虹撰文公开表示，它的安全，它直接暴露在Internet上。作者是相当肯定，有在HTTP解析器（或类似）没有漏洞。不过，笔者不提供任何担保，并表示，用法是在自己的风险。

应用程序服务器相比

在本节中，我将比较我所提到​​的大多数应用程序服务器，但不是的Phusion客运。 Phusion的乘客是，我已经给了它一个专门的部分，其余这样一个不同的野兽。我也省略了特里尼达和TorqueBox，因为我不知道他们做得不够好，但他们只是不相干，如果你使用的JRuby。

• 杂种是pretty裸露的骨头。如前所述，Mongrel是纯粹单线程多进程，所以它是仅在群集是有用的。没有过程监控：如果在集群崩溃的过程（例如，由于在应用程序中的错误），则需要手动重新启动。人们倾向于使用外部进程监视工具，如monit的神。


• 麒麟是杂种狗的叉子。它支持有限的过程监控：如果一个进程崩溃，它会自动由主进程重新启动。它可以使所有进程监听一个共享插槽，而不是为每个进程一个独立的插座。这简化了反向代理配置。杂种一样，纯粹是单线程多进程。


• 薄通过利用EventMachine的库使用事件触发的I / O模型。除了使用的杂种的HTTP解析器，它不以任何方式根据杂种。其集群模式没有过程监控，所以你需要监视崩溃等有没有麒麟般的共享插座，所以每个进程在其自己的套接字监听。从理论上讲，精简的I / O模型允许高并发，但在薄用于大多数实际情况，一种薄的过程只能处理1并发请求，所以你仍然需要一个群集。更多关于章节I / O并发模型这种特殊的属性。


• 彪马也从杂种分叉，但不像麒麟，彪马被设计成纯粹的多线程。有因此目前没有内建集群支持。你需要特别注意，以确保您可以利用多个内核（更多关于此章节I / O并发模型）。


• 彩虹支持通过使用不同的库的多个并发模型。

的Phusion客运

的Phusion客运从所有其他的人完全不同的作品。 Phusion的乘客直接集成到Apache或Nginx的，所以可以比mod_php，并且为Apache。就像mod_php，并且允许Apache以服务于PHP应用程序，几乎是神奇，Phusion的乘客允许Apache（以及Nginx的也是！）服务红宝石的应用程序，几乎是神奇。 Phusion的乘客的目标是使一切只是工作（TM）用尽可能少麻烦越好。

而不是开始为您的应用程序或群集，然后配置Apache / Nginx的为静态文件和/或反向代理请求的过程中/有Phusion的客运集群你只需要：

1. 您编辑Web服务器配置文件，并指定你的Ruby应用程序的公共目录的位置。


2. 有没有第2步。

所有的配置是在Web服务器配置文件中完成的。 Phusion的旅客自动pretty太多的一切。没有必要开始簇和管理流程。启动/停止进程，重新启动他们，当他们崩溃，等等 - 所有的自动化。相对于其他应用服务器，Phusion的乘客已经远远运动部件少。这种易用性就是为什么人们使用的Phusion客运的主要原因之一。

也不像其他的应用服务器，Phusion的乘客主要是用C ++编写，使得它非常快的。

还有的Phusion客运具有更多的功能，如自动滚动重新启动，多线程的支持，部署错误性的企业变种等等。

由于上述原因，旅客的Phusion是目前最流行的Ruby应用服务器，超过15万的网站，包括路数，如纽约时报，皮克斯制作的Airbnb等供电。

的Phusion客运VS其他应用服务器

Phusion的乘客提供了更多的功能，并提供了其他的应用服务器许多优点，如：

• 动态调整的基于交通的进程数。我们运行资源constrainted服务器上一吨的Rails应用是不面向公众的，而且人们在我们的组织最多只用一天几次。像Gitlab，管理平台等的Phusion乘客东西能降速这些流程不是在使用时，和纺纱它们正在使用的时候，可以让更多的资源可用于更重要的应用程序。与其他应用服务器，所有的进程都打开所有的时间。


• 某些应用服务器不擅长某些工作负载，由设计。例如独角兽是专为不仅速度快，运行的请求：请参见独角兽网站在某些情况下只是更糟糕的一节。

工作负载独角兽是不擅长的是：

• 流媒体工作负载（例如轨道4直播或者Rails 4模板流）。


• 工作负载在应用程序执行HTTP API调用。

混合I /在的Phusion客运企业O模型4 或更高版本，使其成为这些类型的工作负载的理想选择。

• 其他应用服务器需要用户运行的每个应用程序至少一个实例。相比之下，Phusion的乘客支持单个实例的多个应用程序。这大大降低了管理费用。


• 自动切换用户，方便的安全功能。


• 的Phusion乘客支持多种MRI的Ruby，JRuby和Rubinius的。杂种，独角兽和薄仅支持MRI检查。彪马也支持所有3。


• 的Phusion客运实际上支持不仅仅是红宝石多！它还支持Python WSGI，所以它可以为例子也运行Django和瓶的应用程序。事实上Phusion的乘客正在走向成为一个通晓多服务器的方向。 Node.js的待办事项清单上的支持。


• 缺货带外的垃圾收集。 Phusion的旅客可以正常的请求/响应周期之外运行Ruby的垃圾收集器，由几百毫秒无形中降低了申请时间。独角兽也有类似的功能，但乘客的Phusion的版本更加灵活，因为
  1）它不是仅限于GC和可以用于任意的工作。
  2）的Phusion乘客的版本与多线程应用效果很好，而独角兽的没有。


• 自动滚动重新启动。关于独角兽和其他服务器重新开始滚动需要一些脚本的工作。乘客的Phusion企业为你完全自动化这个样子。

有更多的功能和优势，但名单是很长的。你应该指的是COM prehensive的Phusion客运手册（ Apache的版本，的 Nginx的版本）或的Phusion的乘客网站信息。

I / O并发模型

• 单线程多进程。这是传统上的Ruby应用服务器最流行的I / O模型，部分原因是因为在Ruby生态系统的多线程支持是非常糟糕。每个进程可以同时处理正好1请求。流程之间的Web服务器负载平衡。这种模式是非常稳健，有很少的机会为程序员介绍并发错误。然而，它的I / O并发极为有限（由进程数量的限制）。这个模型是非常适合于快速，短期运行的工作负荷。这是非常不适合慢，长时间运行的阻塞I / O工作负载，例如工作负载涉及HTTP的API调用。


• 纯粹的多线程。现在Ruby的生态系统具有良好的多线程支持，所以这个I / O模式已经成为非常可行的。多线程允许高I / O并发性，使得它适合短期运行和长时间运行的阻塞I / O工作负载。程序员更容易引进并发错误，但幸运的是大多数Web框架都设计了这样一种方式，这仍是不太可能。有一件事但必须注意的是，MRI的Ruby间preTER甚至无法利用多个CPU内核，当有多个线程，由于使用了全球国米preTER锁（GIL）的。您可以解决此通过使用多个多线程进程，因为每个进程都可以充分利用CPU核心。 JRuby和Rubinius的没有GIL，使他们能够充分利用多内核在一个单一的过程。


• 混合的多线程多进程。主要通过Phusion的客运企业4及更高版本实现的。您可以单线程多进程之间轻松切换，纯粹是多线程的，或者甚至每一个多进程多线程。这种模式提供了最好的两个世界。


• 事件触发。这个模型是从pviously提到的模型$ P ​​$完全不同。它允许非常高的I / O并发性，因此对于长时间运行的阻塞I / O负载优秀。利用它，则需要从应用程序和该框架的明确支持。但是，所有像Rails和Sinatra的大框架不支持事件触发code。这就是为什么在实践薄过程仍不能同时处理多于1请求，使其有效地表现相同单线程多进程的模型。有专门的框架，可以利用事件触发的I / O的优势，如抽筋了。

这是文章最近发布的博客的Phusion关于适当调整的给你的工作量进程和线程数。请参见调整的Phusion乘客的并发设置。

Capistrano的

Capistrano的是完全不同的东西。在所有的previous节，部署是指开始在应用服务器你的Ruby应用程序，使之成为游客轻易获取到的行为，但在此之前可能发生人们通常需要做一些preparation工作如：

• 上传了Ruby应用程序的code和文件到服务器的机器。


• 安装了您的应用程序所依赖的库。


• 设置或迁移数据库。


• 启动和停止你的应用程序可能依赖任何守护进程，如Sidekiq / Resque工人或什么的。


• 需要，当你设置你的应用程序做任何其他事情。

在Capistrano的背景下，部署是指做这一切preparation工作。 Capistrano的是不是一个应用程序服务器。相反，它是用于自动所有preparation工作的工具。你告诉Capistrano的在您的服务器和命令需要运行每次部署应用程序的新版本，并Capistrano的会照顾上传Rails应用程序到服务器为您和运行您指定的命令。

Capistrano的是在组合总是使用与应用服务器。它不会取代应用程序服务器。反之亦然，应用服务器不取代Capistrano的，它们可以在与Capistrano的组合使用。

当然，你不这样做的有无的使用Capistrano的。如果preFER上传你的Ruby应用程序使用FTP和手动运行命令相同的步骤每一次，那么你就可以做到这一点。其他人厌倦了，所以他们在自动化Capistrano的那些步骤。

The whole issue of setting up a development server for my Ruby on Rails application confuses me. There are WEBrick, Mongrel, Passenger, Apache, Nginx and many more I am sure, and I don't really understand the different roles they play.

I started off using WEBrick, and now I use Mongrel for development. Are these servers stand-alone, or do they sit in front of Apache?

I have read about Passenger and I don't really understand what it is, the site says "makes deployment of Ruby web applications a breeze", does it replace Mongrel? Is it like Capistrano, which also deploys web applications?

Bearing in mind I would like to test SSL, and I believe that's not supported by mongrel, what is the best development server setup?

解决方案

The word "deployment" can have two meanings depending on the context. You are also confusing the roles of Apache/Nginx with the roles of other components.

Historic note: This article was originally written on November 6, 2010, when the Ruby app server ecosystem was limited. I've updated this article on March 15 2013 with all the latest updates in the ecosystem.

Disclaimer: I am one of the authors of Phusion Passenger, one of the app servers.

Apache vs Nginx

They're both web servers. They can serve static files but - with the right modules - can also serve dynamic web apps e.g. those written in PHP. Apache is more popular and has more features, Nginx is smaller and faster and has less features.

Neither Apache nor Nginx can serve Ruby web apps out-of-the-box, to do that you need to use Apache/Nginx in combination with some kind of add-on, described later.

Apache and Nginx can also act as reverse proxies, meaning that they can take an incoming HTTP request and forward it to another server, which also speaks HTTP. When that server responds with an HTTP response, Apache/Nginx will forward the response back to the client; You will learn later why this is relevant.

Mongrel and other production app servers vs WEBrick

Mongrel is a Ruby "application server": In concrete terms this means that Mongrel is an application which:

1. Loads your Ruby app inside its own process space.
2. Sets up a TCP socket, allowing it to communicate with the outside world (e.g. the Internet). Mongrel listens for HTTP requests on this socket and passes the request data to the Ruby web app.
3. The Ruby web app then returns an object, which describes what the HTTP response should look like, and Mongrel takes care of converting it to an actual HTTP response (the actual bytes) and sends it back over the socket.

However Mongrel is quite dated, nowadays it is no longer maintained. Newer alternative application servers are:

• Phusion Passenger
• Unicorn
• Thin
• Puma
• Trinidad (JRuby only)
• TorqueBox (JRuby only)

I'll cover them later and describe how they differ from each other and from Mongrel.

WEBrick does the same thing as Mongrel, but the differences are:

• WEBrick is not fit for production, unlike everything else that I mentioned before. WEBrick is written entirely in Ruby. Mongrel (and most other Ruby app servers) is part Ruby and part C (Mostly Ruby), but its HTTP parser is written in C for performance.
• WEBrick is slower and less robust. It has some known memory leaks and some known HTTP parsing problems.
• WEBrick is usually only used as the default server during development because WEBrick is included in Ruby by default. Mongrel and other app servers needs to be installed separately. It's not recommended to use WEBrick in production environments, though for some reason Heroku chose WEBrick as its default server. They were using Thin before, so I have no idea why they switched to WEBrick.

The app server and the world

All current Ruby app servers speak HTTP, however some app servers may be directly exposed to the Internet on port 80, while others may not.

• App servers that can be directly exposed to the Internet: Phusion Passenger, Rainbows
• App servers that may not be directly exposed to the Internet: Mongrel, Unicorn, Thin, Puma. These app servers must be put behind a reverse proxy web server like Apache and Nginx.
• I don't know enough about Trinidad and TorqueBox, so I've omitted them.

Why must some app servers be put behind a reverse proxy?

• Some app servers can only handle 1 request concurrently, per process. If you want to handle 2 requests concurrently you need to run multiple app server instances, each serving the same Ruby app. This set of app server processes is called an app server cluster (hence the name Mongrel Cluster, Thin Cluster, etc). You must then setup Apache or Nginx to reverse proxy to this cluster. Apache/Nginx will take care of distributing requests between the instances in the cluster (More on this in section "I/O concurrency models").
• The web server can buffer requests and responses, protecting the app server from "slow clients" - HTTP clients that don't send or accept data very quickly. You don't want your app server to do nothing while waiting for the client to send the full request or to receive the full response, because during that time the app server may not be able to do anything else. Apache and Nginx are very good at doing many things at the same time because they're either multithreaded or evented.
• Most app servers can serve static files, but are not particularly good at it. Apache and Nginx can do it faster.
• People typically set up Apache/Nginx to serve static files directly, but forward requests that don't correspond with static files to the app server, it's good security practice. Apache and Nginx are very mature and can shield the app server from (perhaps maliciously) corrupted requests.

Why can some app servers be directly exposed to the Internet?

• Phusion Passenger is a very different beast from all the other app servers. One of its unique features is that it integrates into the web server.
• The Rainbows author publicly stated that it's safe to directly expose it to the Internet. The author is fairly sure that there are no vulnerabilities in the HTTP parser (and similar). Still, the author provides no warranty and says that usage is at own risk.

Application servers compared

In this section I'll compare most application servers I've mentioned, but not Phusion Passenger. Phusion Passenger is such a different beast from the rest that I've given it a dedicated section. I've also omitted Trinidad and TorqueBox because I do not know them well enough, but they're only relevant anyway if you use JRuby.

• Mongrel was pretty bare bones. As mentioned earlier, Mongrel is purely single-threaded multi-process, so it is only useful in a cluster. There is no process monitoring: if a process in the cluster crashes (e.g. because of a bug in the app) then it needs to be manually restarted. People tend to use external process monitoring tools such as Monit and God.
• Unicorn is a fork of Mongrel. It supports limited process monitoring: if a process crashes it is automatically restarted by the master process. It can make all processes listen on a single shared socket, instead of a separate socket for each process. This simplifies reverse proxy configuration. Like Mongrel, it is purely single-threaded multi-process.
• Thin uses the evented I/O model by utilizing the EventMachine library. Other than using the Mongrel HTTP parser, it is not based on Mongrel in any way. Its cluster mode has no process monitoring so you need to monitor crashes etc. There is no Unicorn-like shared socket, so each process listens on its own socket. In theory, Thin's I/O model allows high concurrency, but in most practical situations that Thin is used for, one Thin process can only handle 1 concurrent request, so you still need a cluster. More about this peculiar property in section "I/O concurrency models".
• Puma was also forked from Mongrel, but unlike Unicorn, Puma is designed to be purely multi-threaded. There is therefore currently no builtin cluster support. You need to take special care to ensure that you can utilize multiple cores (More about this in section "I/O concurrency models").
• Rainbows supports multiple concurrency models through the use of different libraries.

Phusion Passenger

Phusion Passenger works very differently from all the other ones. Phusion Passenger integrates directly into Apache or Nginx, and so can be compared to mod_php for Apache. Just like mod_php allows Apache to serve PHP apps, almost magically, Phusion Passenger allows Apache (and also Nginx!) to serve Ruby apps, almost magically. Phusion Passenger's goal is to make everything Just Work(tm) with as little hassle as possible.

Instead of starting a process or cluster for your app, and configuring Apache/Nginx to serve static files and/or reverse proxying requests to the process/cluster with Phusion Passenger you only need to:

1. You edit the web server config file and specify the location of your Ruby app's 'public' directory.
2. There is no step 2.

All configuration is done within the web server config file. Phusion Passenger automates pretty much everything. There is no need to start a cluster and manage processes. Starting/stopping processes, restarting them when they crash, etc. - all automated. Compared to other app servers, Phusion Passenger has far fewer moving parts. This ease of use is one of the primary reasons why people use Phusion Passenger.

Also unlike other app servers, Phusion Passenger is primarily written in C++, making it very fast.

There's also an Enterprise variant of Phusion Passenger with even more features, such as automated rolling restarts, multithreading support, deployment error resistance, etc.

For the above reasons, Phusion Passenger is currently the most popular Ruby app server, powering over 150,000 websites, including large ones such as New York Times, Pixar, Airbnb, etc.

Phusion Passenger vs other app servers

Phusion Passenger provides a lot more features and provides many advantages over other app servers, such as:

• Dynamically adjusting the number of processes based on traffic. We run a ton of Rails apps on our resource-constrainted server that are not public-facing, and that people in our organization only use at most a few times a day. Things like Gitlab, Redmine, etc. Phusion Passenger can spin down those processes when they're not used, and spinning them up when they're used, allowing more resources to be available for more important apps. With other app servers, all your processes are turned on all the time.
• Some app servers are not good at certain workloads, by design. For example Unicorn is designed for fast-running requests only: See the Unicorn website section "Just Worse in Some Cases".

Workloads that Unicorn is not good at are:

• Streaming workloads (e.g. Rails 4 live streaming or Rails 4 template streaming).
• Workloads in which the app performs HTTP API calls.

The hybrid I/O model in Phusion Passenger Enterprise 4 or later makes it an excellent choice for these kinds of workloads.

• Other app servers require the user to run at least one instance per application. By contrast, Phusion Passenger supports multiple applications in a single instance. This greatly reduces administration overhead.
• Automatic user switching, a convenient security feature.
• Phusion Passenger supports many MRI Ruby, JRuby and Rubinius. Mongrel, Unicorn and Thin only support MRI. Puma also supports all 3.
• Phusion Passenger actually supports more than just Ruby! It also supports Python WSGI, so it can for example also run Django and Flask apps. In fact Phusion Passenger is moving into the direction of becoming a polyglot server. Node.js support on the todo list.
• Out-of-band garbage collection. Phusion Passenger can run the Ruby garbage collector outside the normal request/response cycle, potentially reducing request times by hundreds of milliseconds. Unicorn also has a similar feature, but Phusion Passenger's version is more flexible because 1) it's not limited to GC and can be used for arbitrary work. 2) Phusion Passenger's version works well with multithreaded apps, while Unicorn's does not.
• Automated rolling restarts. Rolling restarts on Unicorn and other servers require some scripting work. Phusion Passenger Enterprise completely automates this way for you.

There are more features and advantages, but the list is really long. You should refer to the comprehensive Phusion Passenger manual (Apache version, Nginx version) or the Phusion Passenger website for information.

I/O concurrency models

• Single-threaded multi-process. This is traditionally the most popular I/O model for Ruby app servers, partially because multithreading support in the Ruby ecosystem was very bad. Each process can handle exactly 1 request at a time. The web server load balances between processes. This model is very robust and there is little chance for the programmer to introduce concurrency bugs. However, its I/O concurrency is extremely limited (limited by the number of processes). This model is very suitable for fast, short-running workloads. It is very unsuitable for slow, long-running blocking I/O workloads, e.g. workloads involving the calling of HTTP APIs.
• Purely multi-threaded. Nowadays the Ruby ecosystem has excellent multithreading support, so this I/O model has become very viable. Multithreading allows high I/O concurrency, making it suitable for both short-running and long-running blocking I/O workloads. The programmer is more likely to introduce concurrency bugs, but luckily most web frameworks are designed in such a way that this is still very unlikely. One thing to note however is that the MRI Ruby interpreter cannot leverage multiple CPU cores even when there are multiple threads, due to the use of the Global Interpreter Lock (GIL). You can work around this by using multiple multi-threaded processes, because each process can leverage a CPU core. JRuby and Rubinius have no GIL, so they can fully leverage multiple cores in a single process.
• Hybrid multi-threaded multi-process. Primarily implemented by Phusion Passenger Enterprise 4 and later. You can easily switch between single-threaded multi-process, purely multithreaded, or perhaps even multiple processes each with multiple threads. This model gives the best of both worlds.
• Evented. This model is completely different from the previously mentioned model. It allows very high I/O concurrency and is therefore excellent for long-running blocking I/O workloads. To utilize it, explicit support from the application and the framework is required. However all the major frameworks like Rails and Sinatra do not support evented code. This is why in practice a Thin process still cannot handle more than 1 request at a time, making it effectively behave the same as the single-threaded multi-process model. There are specialized frameworks that can take advantage of evented I/O, such as Cramp.

An article was recently posted on the Phusion blog about optimally tuning the number of processes and threads given your workload. See Tuning Phusion Passenger's concurrency settings.

Capistrano

Capistrano is something completely different. In all the previous sections, "deployment" refers to the act of starting your Ruby app in an application server, so that it becomes accessible to visitors, but before that can happen one typically needs to do some preparation work, such as:

• Uploading the Ruby app's code and files to the server machine.
• Installing libraries that your app depends on.
• Setting up or migrating the database.
• Starting and stopping any daemons that your app might rely on, such as Sidekiq/Resque workers or whatever.
• Any other things that need to be done when you're setting up your application.

In the context of Capistrano, "deployment" refers to doing all this preparation work. Capistrano is not an application server. Instead, it is a tool for automating all that preparation work. You tell Capistrano where your server is and which commands need to be run every time you deploy a new version of your app, and Capistrano will take care of uploading the Rails app to the server for you and running the commands you specified.

Capistrano is always used in combination with an application server. It does not replace application servers. Vice-versa, application servers do not replace Capistrano, they can be used in combination with Capistrano.

Of course you don't have to use Capistrano. If you prefer to upload your Ruby app with FTP and manually running the same steps of commands every time, then you can do that. Other people got tired of it, so they automate those steps in Capistrano.

这篇关于Ruby on Rails的服务器选项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！