Ruby on rails 3 由于Rack:：Lock，Rails应用程序面临性能问题

我有一个Ruby on Rails应用程序，其版本如下：

红宝石：1.9.3-p547

轨道：3.2.16

我在此应用程序中面临一些性能问题。我在诊断这一问题上的最初努力使我不得不使用在上一篇文章中提到的RackTimer gem（）来记录中间件的时间戳

使用它，我发现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:

涉及的中间产品：

开发环境日志：

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

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

谢谢，

---

Jignesh

在我将我的问题发布在上面之后，我将我的发现发布在这里。希望其他人在出现上述情况时能从这些发现中获益

与我的一位高级同事Juha Litola讨论Rack:：Lock的问题，以下是他的第一个想法（引用他自己的话）：

您是否有可能看到测量工件在某种意义上，您只是看到Rack:：Lock占用了很多时间，但这仅仅是因为它正在包装实际调用？因此，Rack:：Lock time是请求处理过程中发生的所有事件的累积时间。看

至于性能问题，您能否详细说明您有哪些问题，以便我提供帮助

我认为这是可能的。然而，由于以下疑问，我无法用这种可能性说服自己：

Rack:：Lock

是Rails应用程序在中间件链中的第二个位置（请参阅我在上面的帖子中提到的中间件列表）。每个中间件在链中按顺序进行处理。因此，

Rack:：Lock

将是处理请求的第二个 然后链中的其他人将有机会加入

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

稍后，Juha在花了几分钟查看服务器（见下面的注释）后，配置提供了以下输入：

通过快速查看，我认为在应用程序的配置中存在一个非常明显的问题。 应用程序没有config.threadsafe！enabled，这意味着Rack:：Lock已启用，请求处理仅限于一个线程/进程。现在puma配置为只有一个进程，但有16-32个线程。这实际上意味着puma目前在给定时刻只处理一个请求

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

注意：我忘记添加有关部署应用程序的web服务器配置的任何详细信息。我们正在使用Puma Web服务器（）

有了这一点，我得到了一个提示，要深入研究config.threadsafe。在网上搜索时，我发现了以下文章

关于如何启用或禁用选项config.threadsafe的深刻见解影响部署在多线程或多进程Web服务器上的应用程序在生产中的性能

上述文章所传达内容的简要总结

什么是机架：：锁？

Lock是一个插入Rails中间件堆栈的中间件，用于保护我们的应用程序免受多线程怪物的攻击。这个中间件应该通过使用互斥对象包装请求来保护我们免受恶劣的竞争条件和死锁的影响。中间件在请求开始时锁定互斥锁，在请求完成时解锁互斥锁

让我们假设有一个程序正在运行，并将5个请求同时100次发送到一个代码（比如控制器）不是线程安全的应用程序

现在让我们观察一下Rack:：Lock中间件config.threadsafe组合的影响！启用或禁用选项，在程序完成或终止后，在应用程序中执行不安全的代码，以及多线程或多进程Web服务器

多线程Web服务器（Puma）

注：示例和运行时统计数据引用自

多进程Web服务器（Unicorn）

结论：

• 在多进程环境中，如果我们保持config.threadsafe，Rack:：Lock将变得多余！选项已禁用。 这是因为在多进程环境中，套接字是我们的锁，我们不需要任何额外的锁。 因此，启用config.threadsafe是有益的！并拆下机架锁

  # 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
  

  # 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.