为什么我的 sinatra 网站这么慢？答案

【问题标题】：Why is my sinatra website so slow?为什么我的 sinatra 网站这么慢？
【发布时间】：2011-01-08 23:24:10
【问题描述】：

在询问this question, 之后，我开始使用 Sinatra 作为网页服务的一种方式。

今天晚上，我和一个朋友开始测试服务器的速度。

登录文件如下：

require 'rubygems'
require 'sinatra'
require 'haml'

enable :sessions #for cookies!

get '/' do 
  haml :index 
end

index.haml 看起来像：

%title
  First Page

%header 
  %h2 First Page

他和我一样坐在最近的笔记本电脑上，我们两个之间有一个 Apple 802.11n 路由器。我们都在运行 Windows 7。我还在运行带有 Sinatra 的 Ubuntu 9.10 x64 的笔记本电脑上尝试了这些相同的文件，并且所有相关文件都是从 apt-get 安装的。

无论服务器操作系统、Windows 还是 Linux，Sinatra 都需要 7 秒来处理单个页面请求。我看到here 作者设法处理了超过 400 个请求/秒。是什么赋予了？（或者这应该在 SuperUser 之类的吗？）

【问题讨论】：

它可能是您的配置正在使用的服务器。例如，WEBrick、Thin 和 Mongrel 之间存在重大差异。你如何启动你的 sinatra 应用程序？
从命令行；基本上，我们运行“ruby TestServer.rb”，然后连接到端口 4567。我对此完全不了解，所以如果有这类事情的指南，请让我知道。

标签： performance sinatra

【解决方案1】：

我正在使用 Vagrant 在 VMWare Fusion 中运行 Sinatra。我的应用程序运行缓慢（大约十秒钟来处理请求）。然后我发现了这个宝石：

Webrick is very slow to respond. How to speed it up?

WEBrick 似乎（默认情况下）配置为对每个请求进行反向 dns 查找，这降低了它的速度。

【讨论】：

【解决方案2】：

我在使用 Shotgun 运行 Sinatra 时遇到了这个问题，但在直接运行我的应用程序时没有（即ruby -rubygems app.rb）。这是因为 Shotgun 会为每个请求分叉并重新加载应用程序。

我找到了一个讨论这个问题的thread in Sinatra's mailing list，那里的人建议使用rerun 而不是shotgun。我很高兴地说它为我解决了这个问题。

【讨论】：

谢谢！刚刚安装重新运行，应用程序再次正常加载。我认为 shotgun 会减慢速度，但并不是说它实际上会为每个请求重新加载应用程序（包括所有资产，即使只是在开发模式下进行测试也会降低性能）。

【解决方案3】：

对于您何时应该优化您的网络应用程序，我将搁置任何意见。

在您的 Sinatra 应用程序中为开发和生产设置不同的配置，因为其中一些建议您不会总是想要使用。事实上，您可能应该继续设置和环境，类似于您在生产中的部署方式。您不会通过简单地运行ruby app.rb 来进行部署。你想把 apache 或 nginx 放在你的 Mongrel 前面。 Mongrel 将提供您的静态文件，但这实际上只适用于开发模式。在部署中，Web 服务器会为此做得更好。简而言之，您的部署环境将比您的独立开发环境更快。

在这一点上，我不会担心 Mongrel 和 Thin。如果 Thin 的速度是原来的两倍——它不是——那么你的 7 秒变成了 3.5 秒。这样就够了吗？

尝试一些事情...

我知道我刚刚告诉你设置一个部署环境，但可能不是服务器端。您是否尝试过在您的页面上运行YSlow 或PageSpeed？ I/O 将比服务器占用更多的这 7 秒（免责声明：我假设您的网络设置没有问题）。 YSlow - 实际上是 Firebug - 会告诉您页面的每个部分需要多长时间才能到达浏览器。

YSlow 告诉我要做的一件事是在我的静态资产上放置一个很远的 Expires 标头，我知道这一点，但我将优化留到最后。那时我意识到至少有3 different places that I could specify that header。我说服自己在 nginx 中做这件事是放置它的正确位置。

如果您对这些结果感到满意，那么您可以查看服务器。在我的脑海中，所以不是详尽的

开启 gzip 响应。
组合您的样式表，这样每个页面请求只有一个。如果您不手动执行此操作，可能会有一些机架中间件。
缓存。我正在尝试Rack::Cache。
使用 sprite 减少您使用的图片下载次数。
缩小您的 Javascript。同样，也许通过机架中间件。

机架中间件很简洁，但它使用 CPU。因此，手动缩小 Javascript 为您的工作流程增加了一个新步骤，但在服务器上，它比中间件更快。这是一个权衡。

抱歉，如果这是漫不经心的。

【讨论】：

感谢您的彻底回复！你在'远前Expires header'中失去了我，在那之后，我了解了我无知的深度。我想我还有很多事情要做。
这是我从 Yahoo! Y慢网站。 developer.yahoo.com/performance/rules.html。它只是意味着将 Expires 标头设置为将来的某个时间点。比如说 20 年。
我之所以选择这个作为答案，纯粹是因为一旦我通过 Hello World，它会导致学习很多关于优化的知识。在这种情况下，解决方法是在 webrick 中进行调试。
“我将搁置关于何时优化 Web 应用程序的任何意见。” - pffft，他在一个微不足道的实现中获得了 0.14 个请求/秒，当然他现在应该调查一下。

【解决方案4】：

尝试使用 Thin 作为服务器。我注意到与 WEBrick 和 Mongrel 相比，性能有所提高。

gem install thin

当您使用ruby TestServer.rb 运行您的应用程序时，您将看到以下内容：

Sinatra/0.10.1 在 Thin

的支持下在 4567 上进行开发

【讨论】：

我从 gem 得到的 sinatra 版本是 0.9.4；我也应该获得其他更新的版本吗？
我从 github 获得了 0.10.1 版本。 gem install sinatra-sinatra --source=gems.github.com
顺便说一句，thin 不能在没有nmake 的Windows 上工作（即，显然没有Windows 64 位版本）。 Mongrel 应该可以正常工作。
此外，Windows 上的 Thin 在提供缓存的静态资源方面非常缓慢，至少在开发模式下是这样。在空闲的 2.8GHz 8 核 8GB 机器上从 localhost 提供服务，需要 6.2s 来处理 36 个请求（其中 35 个是状态：304），总计 13.25kB。清除缓存并重新发出该请求仅在 2.2s 内传输 36 个（状态：200）请求，总计 454kB。在另一个机器上反向代理 Nginx 后面的所有这些 - 使用两台机器 - 缓存案例需要 99 毫秒，未缓存案例需要 156 毫秒。当您必须使用 Windows 作为服务器时，我仍然推荐 Thin，但不单独推荐 Thin。