My Rails-Anwendung verwendet das inherited_resources
Gem. Ich versuche derzeit, es zu beschleunigen, um mit einem viel größeren Datensatz umgehen zu können. Also ging ich (mit Hilfe des Bullet Gem) nach vorne, um eifrig zu laden, wo es sich als hilfreich erweisen würde. Innerhalb inherited_resources sieht es so etwas wie dieses:Wie kann ich diesen Fehler beheben, während ich das Eager-Laden erhöht? "ERROR ThreadError: Versuch, einen Mutex zu entsperren, der von einem anderen Thread gesperrt ist"
def collection
my_widgets ||= end_of_association_chain.includes(:association_one, :association_two, :association_three, :association_four)
@widgets = case params[:filter]
when nil then my_widgets.all
when 'old' then my_widgets.old
when 'new' then my_widgets.new
end
@final_collection
end
Der neue Code ist .includes(:association_one, :association_two, :association_three, :association_four)
Diese einfache Änderung meine Ladezeit in den Protokollen riesige Datenbank von ca. 5 mal für meinen Test beschleunigt. Der Browser würde jedoch einfach da sitzen, leer. Nichts. Mit dem Chrom-Ladesymbol gehen.
Wenn ich den Server im Terminal töten, erhalte ich diese ziemlich einzigartig Fehler:
ERROR ThreadError: Attempt to unlock a mutex which is locked by another thread
Backtrace am unteren Ende.
Ich habe bereits versucht, die Lösung in der Top-Antwort auf diese Frage diskutiert: How can I serve requests concurrently with Rails 4?, mit dem folgenden:
#config/environments/development.rb
config.cache_classes = false
config.eager_load = true
config.allow_concurrency=true
Was bin ich hier? Warum verleiht mir das Hinzufügen dieser Assoziationen zum Eager-Laden, das die Dinge hinter den Kulissen erheblich beschleunigt, mit diesem ThreadError einen nicht reagierenden Browser?
/Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/lock.rb:22:in `unlock' /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/lock.rb:22:in `ensure in call' /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/lock.rb:23:in `call' /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/content_length.rb:15:in `call' /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/handler/webrick.rb:88:in `service' /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/httpserver.rb:138:in `service' /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/httpserver.rb:94:in `run' /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:294:in `block in start_thread' /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/handler/webrick.rb:48:in `shutdown': undefined method `shutdown' for nil:NilClass (NoMethodError) from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/server.rb:280:in `block in start' from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:206:in `call' from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:206:in `join' from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:206:in `block (2 levels) in start' from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:206:in `each' from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:206:in `block in start' from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:32:in `start' from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:162:in `start' from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/handler/webrick.rb:34:in `run' from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/server.rb:286:in `start' from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/server.rb:80:in `start' from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/commands_tasks.rb:80:in `block in server' from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/commands_tasks.rb:75:in `tap' from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/commands_tasks.rb:75:in `server' from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/commands_tasks.rb:39:in `run_command!' from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands.rb:17:in `' from bin/rails:4:in `require' from bin/rails:4:in `'
edit: Ich fange an zu fragen, ob dies weniger einen Thread Fehler ist als meine Daten-Set zu groß für eifrigen Laden zu sein, gibt es eine Schwelle, wo Sie gerne Laden sind so viele Objekte, die, während sie schnell geladen im Terminal sitzt der Browser einfach für immer da?
Ich habe zu Unicorn gewechselt, um zu testen, es scheint * diesen Fehler zu stoppen, indem er für jetzt vorwarnte, aber er ist immer noch funktionsfähig über ungefähr 5.000 Objekte. Ich fange an mich zu fragen, ob es eine Lastgrenze gibt, die mein Browser von Active-Records-Objekten gleichzeitig verarbeiten kann. – Schwad
Dies hat den Fehler behoben. Das größere Problem scheint zu sein, dass ich Daten nicht optimal behandelte und ActiveRecord etwas zu sehr missbrauchte. – Schwad