Rails应用程序由于Rack::Lock而面临性能问题

Question

我有一个Ruby on Rails应用程序，有以下版本:

Ruby: 1.9.3-p547

Rails: 3.2.16

我在这个应用程序中面临一些性能问题。我在诊断这个问题上的最初努力使我使用文章中提到的RackTimer gem (https://github.com/joelhegg/rack_timer)在http://www.codinginthecrease.com/news_article/show/137153记录中间件时间戳。

使用它我发现Rack::Lock消耗了很多时间。例如:下面提供了一些RackTimer日志:

Rack Timer (incoming) -- Rack::Lock: 73.77910614013672 ms
Rack Timer (incoming) -- Rack::Lock: 67.05522537231445 ms
Rack Timer (incoming) -- Rack::Lock: 87.3713493347168 ms
Rack Timer (incoming) -- Rack::Lock: 59.815168380737305 ms
Rack Timer (incoming) -- Rack::Lock: 55.583953857421875 ms
Rack Timer (incoming) -- Rack::Lock: 111.56821250915527 ms
Rack Timer (incoming) -- Rack::Lock: 119.28486824035645 ms
Rack Timer (incoming) -- Rack::Lock: 69.2741870880127 ms
Rack Timer (incoming) -- Rack::Lock: 75.4690170288086 ms
Rack Timer (incoming) -- Rack::Lock: 86.68923377990723 ms
Rack Timer (incoming) -- Rack::Lock: 113.18349838256836 ms
Rack Timer (incoming) -- Rack::Lock: 116.78934097290039 ms
Rack Timer (incoming) -- Rack::Lock: 118.49355697631836 ms
Rack Timer (incoming) -- Rack::Lock: 132.1699619293213 ms

可以看到Rack::Lock中间件的处理时间在10毫秒到130多秒之间波动。这些大部分都是在我的主页上提供资源时出现的。

顺便说一句，我在config/application.rb中启用了资产管道

# Enable the asset pipeline
config.assets.enabled = true

我有我的生产版本应用程序配置为由NewRelic监控。图中还显示了Rack::Lock占用的最高百分比和时间。

我完全不知道是什么导致Rack::Lock花了这么多毫秒。如果社区中的任何人可以提供宝贵的指导，找出可能导致这种情况的原因以及如何修复它，我将不胜感激。

下面可以找到Gemfile，所有中间件涉及和Dev环境日志。

Gemfile:

https://gist.github.com/JigneshGohel-BoTreeConsulting/1b10977de58d09452e19

中间件):

https://gist.github.com/JigneshGohel-BoTreeConsulting/91c004686de21bd6ebc1

开发环境日志:

-----第一次加载主页索引页

https://gist.github.com/JigneshGohel-BoTreeConsulting/990fab655f156a920131

-----第二次加载主页索引页而未重新启动服务器

https://gist.github.com/JigneshGohel-BoTreeConsulting/f5233302c955e3b31e2f

谢谢,Jignesh

Answer 1

我在上面发布了我的问题之后，在这里发布了我的发现。希望当别人遇到类似的情况时，能从这些发现中受益。

关于Rack::Lock与我的一位高级同事Juha Litola的问题，下面是他的第一个想法(引用他自己的话):

是否有可能您在某种意义上看到度量工件，您只是看到Rack::Lock花费了大量时间，但这仅仅是因为它包装了实际的调用?因此Rack::Lock时间是请求处理中发生的所有事情的累积时间。看到

https://github.com/rack/rack/blob/master/lib/rack/lock.rb。

关于性能问题，你能详细说明你有什么问题，以便我能帮助你吗?

我认为这是有可能的。然而，由于以下的疑问，我不能说服自己这种可能性:

Rack::Lock与Rails应用程序在中间件链中的第二个位置(请参阅我在https://gist.github.com/JigneshGohel-BoTreeConsulting/91c004686de21bd6ebc1上面提到的中间件列表)。每个中间件在链中按顺序处理。因此，Rack::Lock将是第二个处理请求的服务器然后链中的其他人就有机会加入。

在这种情况下，根据我的理解，我不认为为Rack::Lock中间件记录的时间戳是请求处理中发生的所有事情的累积时间。它应该是Rack::Lock中间件本身所花费的时间。

之后，在花了几分钟查看服务器(见下面的注释)之后，Juha提供了以下输入:

通过快速查看，我认为应用程序的配置方式存在相当明显的问题。应用程序没有config.threadsafe!启用，这意味着启用了Rack::Lock，并且请求处理仅限于一个线程/进程。现在puma被配置为只有一个进程，但是有16-32个线程。这实际上意味着puma当前在给定时刻只处理一个请求。

最好的解决方案当然是启用线程安全模式，但这需要彻底的测试。如果失败或者不是一个选项，puma应该配置多个worker，每个worker有一个线程。

注意:我忘记添加有关部署应用程序的web服务器配置的任何详细信息。我们使用Puma Web Server (https://github.com/puma/puma)

有了这个，我得到了一个提示，可以更深入地研究config.threadsafe!

． 在网上搜索时，我找到了以下文章 http://www.sitepoint.com/config-threadsafe/

http://tenderlovemaking.com/2012/06/18/removing-config-threadsafe.html

揭示了如何启用或禁用选项config.threadsafe!影响在生产环境中部署在多线程或多进程web服务器上的应用程序的性能。

什么是Rack::Lock?

Rack::Lock是一个插入到Rails中间件堆栈中的中间件，目的是保护我们的应用程序免受多线程的威胁。这个中间件应该通过用互斥锁包装我们的请求来保护我们免受恶劣的竞争条件和死锁的影响。中间件在请求开始时锁定互斥锁，并在请求结束时解锁互斥锁。

让我们假设有一个程序正在运行并同时向一个应用程序发送100次5个请求，该应用程序的代码(例如Controller)不是线程安全的。

现在让我们观察机架::锁中间件，config.threadsafe组合的影响!选项启用或禁用，应用程序中的线程不安全代码，多线程或多进程Web服务器，程序完成或终止后

多线程Web服务器(Puma)

# Combination 1:
config.threadsafe! option   : Disabled
Rack::Lock middleware       : Available in app's middleware stack because of config.threadsafe! option disabled
With this combination the web server is successfully able to entertain all the 500 requests received.
This is because each request is augmented by Rack::Lock so as to execute it synchronously.In other words
Rack::Lock ensures we have only one concurrent request at a time.Thus each of the 500 requests gets a chance to
execute.
# Combination 2:
config.threadsafe! option   : Enabled
Rack::Lock middleware       : Unavailable in app's middleware stack because of config.threadsafe! option enabled
With this combination the web server is able to entertain only 200 out of 500 requests received.
This is because of the absence of Rack::Lock middleware, which ensures that we have only one concurrent request
at a time and thus each request gets a chance.
However there are advantages as well as disadvantages of each combination mentioned above:
# Combination 1
Advantage:
Each of the request received gets chance to be processed
Disadvantage:
* The runtime to process all of the 500 requests took 1 min 46 secs (compare it to runtime of Combination 2)
* Using a multi-threaded webserver is useless, if Rack::Lock remains available in middleware stack.
# Combination 2
Advantage:
The runtime to process 200 requests took 24 secs (compare it to runtime of Combination 1).
The reason being the multi-threaded nature of webserver is being leveraged in this case to entertain concurrent requests coming in.
Disadvantage:
* Not all 500 requests got a chance to be processed

注意:示例和运行时统计数据引用自http://tenderlovemaking.com/2012/06/18/removing-config-threadsafe.html

多进程Web服务器(Unicorn)

# Combination 1:
config.threadsafe! option   : Disabled
Rack::Lock middleware       : Available in app's middleware stack because of config.threadsafe! option disabled
Since multiple processes are forked by the webserver and each of them listens for requests and also
Rack::Lock middleware is available, the web server is successfully able to entertain all the 500 requests received.
# Combination 2:
config.threadsafe! option   : Enabled
Rack::Lock middleware       : Unavailable in app's middleware stack because of config.threadsafe! option enabled
Here too multiple processes are forked by the webserver and each of them listens for requests,
however Rack::Lock middleware is unavailable which enables multi-threading, which in turn means that we'll
get a race condition in the thread-unsafe code we have in the application.But strangely with this combination
too the web server is successfully able to entertain all the 500 requests received.
The reason being a process-based web server creates worker processes and each process holds one instance of
our application. When a request is received webserver spawns a child process for handling it.

结论:

• 在多进程环境中，如果我们保持config.threadsafe, Rack::Lock会变得多余!选择禁用。这是因为在多进程环境中，套接字是我们的锁，我们不需要任何额外的锁。因此，启用config.threadsafe是有益的!

  删除生产环境中的Rack::Lock开销。

• 在多线程环境中，如果我们保持config.threadsafe!开发人员需要确保应用程序的代码是线程安全的。以及保持config.threadsafe的好处!是需要较少的运行时间来处理传入的请求。

在我的应用程序上下文中，我们通过增加worker来调整Puma服务器的配置。我希望性能能提高。