Ruby on rails 开发模式下的异常页面需要15-30秒才能呈现，这是为什么？

我使用的是Rails 3 beta 4，出于某种原因，每个异常都需要15-30秒才能显示出来。这是我的追踪：

Started GET "/something/something/approvals/new" for 127.0.0.1 at Thu Jun 24 21:17:12 -0400 2010
  SQL (1.8ms)  describe `approvals_users`
  SQL (24.6ms)  describe `clients_users`
  SQL (1.4ms)  describe `agencies_users`
  SQL (1.2ms)  describe `clients_users`
  SQL (1.2ms)  describe `approvals_users`
  SQL (1.7ms)  describe `permissions_users`
  Processing by ApprovalsController#new as HTML
  Parameters: {"project_id"=>"tricked", "client_id"=>"deez-nutz"}
  SQL (1.4ms)  describe `agencies_users`
  Agency Load (0.4ms)  SELECT `agencies`.* FROM `agencies` WHERE (`agencies`.`subdomain` = 'subdomain') LIMIT 1
  Plan Load (0.3ms)  SELECT `plans`.* FROM `plans` WHERE (`plans`.`id` = 3) LIMIT 1
  User Load (0.4ms)  SELECT `users`.* FROM `users` WHERE (`users`.`id` = 1) LIMIT 1
Completed   in 93ms

NoMethodError (undefined method `humanize' for nil:NilClass):
  app/models/approval.rb:38:in `state'
  app/models/approval.rb:38:in `state'
  app/controllers/approvals_controller.rb:10:in `new'
  app/controllers/approvals_controller.rb:10:in `new'

Rendered /Users/garrett/.bundle/ruby/1.8/bundler/gems/rails-07b08721a226ff01f983e61d99ab4da96e296c97-6682cce0386811ffe3e6d31fc025ede0936d86c3/actionpack/lib/action_dispatch/middleware/templates/rescues/_trace.erb (0.9ms)
  SQL (2.5ms)  SHOW TABLES
  SQL (0.9ms)  SHOW TABLES
  SQL (0.9ms)  SHOW TABLES
  SQL (0.9ms)  SHOW TABLES
  SQL (0.9ms)  SHOW TABLES
  SQL (0.9ms)  SHOW TABLES
  SQL (0.9ms)  SHOW TABLES
  SQL (0.9ms)  SHOW TABLES
Rendered /Users/garrett/.bundle/ruby/1.8/bundler/gems/rails-07b08721a226ff01f983e61d99ab4da96e296c97-6682cce0386811ffe3e6d31fc025ede0936d86c3/actionpack/lib/action_dispatch/middleware/templates/rescues/_request_and_response.erb (21433.7ms)
Rendered /Users/garrett/.bundle/ruby/1.8/bundler/gems/rails-07b08721a226ff01f983e61d99ab4da96e296c97-6682cce0386811ffe3e6d31fc025ede0936d86c3/actionpack/lib/action_dispatch/middleware/templates/rescues/diagnostics.erb within rescues/layout (21630.2ms)

如果有帮助的话，这是我的

Gemfile

：

source 'http://gemcutter.org'

# Core
# gem 'rails', '3.0.0.beta4'
gem 'rails', :git => 'http://github.com/rails/rails.git'
gem 'sinatra'
gem 'mysql'
gem 'bundler'
gem 'memcache-client'
gem 'system_timer'
gem 'mime-types', :require => 'mime/types'
gem 'json'
gem 'haml', '~> 3.0.12'
gem 'state_machine'
gem 'bcrypt-ruby', :require => 'bcrypt'
gem 'juicer'
gem 'hoptoad_notifier'
gem 'braintree'
gem 'panda'

# Templating
gem 'liquid', '2.0.0'

# Users
gem 'warden'
gem 'ruby-openid', :require => 'openid'
gem 'canable'
gem 'devise'

# Paperclip
gem 'aws-s3', :require => 'aws/s3'
gem 'paperclip', :git => 'git://github.com/dewski/paperclip.git', :branch => 'rails3'
gem 'delayed_job', :git => 'git://github.com/dewski/delayed_job.git'

group :test do
  gem 'webrat'
  gem 'hpricot'
  gem 'mocha', :require => false
end

---

如果我创建一个新的Rails应用程序，错误页面会立即显示。在Rails源代码中，

SHOW TABLES

的方法是

structure\u dump

In

schema\u statements.rb

。我在bundler目录中搜索了对该方法的任何调用，但没有显示任何内容。was

SHOW TABLES

会被反复调用，并且可能会使每个方法都很难调试，这会给was

SHOW TABLES带来什么以及如何导致这种情况？
rails项目中也存在类似问题：

我的测试套件中也有同样的问题，但还没有找到解决方案。
我们公司遇到了这个问题，在等待Rails point正式发布的过程中，我们进行了一次黑客攻击。另一个答案中链接的Lighthouse ticket中提到的关键问题似乎是，对于某些应用程序，
request.env
包含一些对象，这些对象的
#inspect
输出非常大（比如，兆字节的文本），并且这些输出都被放入错误页面

这就是：

# development.rb

config.after_initialize do    
  module SmallInspect
    def inspect
      "<#{self.class.name} - tooooo long>"
    end
  end
  [ActionDispatch::RemoteIp::RemoteIpGetter, OmniAuth::Strategies::Facebook, ActionController::Base, Warden::Proxy].each do |klazz|
    klazz.send(:include, SmallInspect)
  end
end

#development.rb
config.after\u初始化do
模块SmallInspect
def检查
""
结束
结束
[ActionDispatch:：RemoteIp:：RemoteIpGetter，OmniAuth:：Strategies:：Facebook，ActionController:：Base，Warden:：Proxy]。每个do | klazz|
klazz.send（：include，SmallInspect）
结束
结束

列出的类别是我们的主要罪魁祸首；根据您的应用程序，您的应用程序会有所不同。
您的控制器中是否有救援或类似的东西？我有，但即使我取出它们，也不会改变响应的长度。这是一个很长的过程，但我习惯于在出现30秒错误时，丢失DNS条目是常见的罪魁祸首。我注意到您的错误日志中有一个127.0.0.1（顶行）——可能系统试图将IP反向解析为name。/etc/hosts是否有
127.0.0.1 localhost
行？如果所有这些都失败了，您可以带上火箭筒：在Linux上，您可以跟踪或远程跟踪处理请求的rails实例。在MacOSX上，您可以使用ktrace/kdump获取系统调用，但不知道库调用。这将是一个巨大的信息堆，但它将记录丢失的30秒。我的/etc/hosts文件中有
127.0.0.1 localhost
，它已经存在了。Hackish，但你可以将
raise“this”
放在控制器操作的顶部，看看延迟是在这之前还是之后，然后进行调整，试图找到令人不快的路线。它会发生在其他控制器中吗？其他行动？你有没有试过git最新的rails，看看它是否与框架相关并且已经修复了？这是我的问题。这是一个大型应用程序吗？新应用程序？我还注意到在异常之前加载的所有模型，获取
SHOW TABLES
调用。Garrett，你在使用mysql2吗？你能从运行show tables的方法中发布一个回溯吗？我在这里得到了回溯：通过将此代码添加到mysql2适配器的“tables”方法中<代码>开始升起救援警告“”$！。backtrace.each{m|warn m}end

Garrett，为了回答您的问题，我创建了一个几乎普通的rails应用程序来重新处理这个问题。我在火车票上链接到它。我还在一个大型应用程序中看到，我正在升级到rails3，这是一个非常糟糕的问题，因为我拥有的模型数量和测试套件中生成的异常数量（升级过程中出现的测试中断）。我的测试套件在报告异常时会触发数千个“显示表”。是的，这对我很有用。我会让悬赏暂时开放，以吸引任何路过的人的注意。谢谢完美的我正要在同一行上发帖……）