Webrick bardzo wolno reaguje. Jak to przyspieszyć?

Mam aplikację Rails, którą uruchamiam na swoim serwerze. Kiedy przechodzę do zdalnego pulpitu i próbuję załadować aplikację, serwer potrzebuje dobrych 3-4 minut, aby odpowiedzieć za pomocą prostej strony HTML. Jednak gdy ładuję stronę lokalnie na serwerze, pojawia się ona w ciągu zaledwie sekundy. Próbowałem pingować serwer z mojego zdalnego pulpitu i pingy są pomyślne w rozsądnym czasie.

Wydaje się, że wszystko zaczęło się po zainstalowaniu podstawowego klienta Oracle i SQLPLUS. Powinienem podejrzewać Oracle? Czy ktoś doświadczył czegoś podobnego?

Mając tutaj ten sam problem (nawet rok później). W Linuksie musisz wykonać następujące czynności:

Poszukaj pliku /usr/lib/ruby/1.9.1/webrick/config.rb i edytuj go.

Wymień linię

:DoNotReverseLookup => nil,

z

:DoNotReverseLookup => true,

Zrestartuj webrick i będzie działać jak urok :)

Miałem ten sam problem. Dla mnie to stanowisko było rozwiązaniem. Jeśli korzystasz z Ubuntu, zatrzymaj (lub odinstaluj) plik avahi-daemon. service avahi-daemon stopzatrzymuje demona.

Webrick wydaje się teraz bardzo szybki.

Problem ma stary raport w Rails Lighthouse , jednak od tego czasu Ruby-on-Rails przeniósł swoje bilety na github ; Trochę niefortunne, że ten stary problem nadal występuje.

Pamiętaj jednak, że jeśli faktycznie używasz avahi-daemon do czegoś, na przykład wyszukiwania drukarek i skanerów w sieci, to już nie zadziała.

Po prostu miałem ten sam problem. Plik

...
:DoNotReverseLookup => true,
...

dla mnie też załatwił sprawę. Na wypadek, gdybyś korzystał z Ruby pod rvm, oto ścieżka do:

~/.rvm/rubies/ruby-<version>/lib/ruby/<version>/webrick/config.rb

„Cienki” jest teraz doskonałą opcją do uruchamiania zarówno lokalnie i na Heroku:

Strona internetowa: http://code.macournoyer.com/thin/

Możesz go używać lokalnie, umieszczając plik Gemfile:

gem "thin"

... a następnie uruchom pakiet i uruchom serwer za pomocą thin startlub rails s.

Aktualizacja w Heroku

Cienki jest teraz uważany za zły wybór dla Heroku. Więcej informacji tutaj:

https://blog.heroku.com/archives/2013/4/3/routing_and_web_performance_on_heroku_a_faq

Ich rekomendacja:

Przełącz się na współbieżne zaplecze internetowe, takie jak Unicorn lub Puma na JRuby, co pozwala hamowni zarządzać własną kolejką żądań i unikać blokowania długich żądań.

Miałem dość podobny problem, który objawił się podczas uzyskiwania dostępu do serwera WEBrick przez VPN. Żądania zajęłyby dużo czasu, a większość z nich nic się nie działo. Ponieważ mongrelani thinklejnoty, ani klejnoty nie działały z Ruby 1.9 w systemie Windows i nie było sposobu, abym był wplątany w kompilowanie rzeczy ze źródeł, musiałem pozostać przy WEBrick.

Poprawka polegała na ustawieniu parametru config DoNotReverseLookupna true, podczas tworzenia serwera WEBrick:

server = HTTPServer.new {:DoNotReverseLookup => true, ...}

Możesz użyć Apachelub zainstalować Thin. W twoim Gemfile:gem 'thin'

Możesz również sprawdzić listę serwerów WWW dla szyn .

Próbowałem to zrobić z webrick na 1.8.7 i nie mogłem znaleźć konfiguracji do zmiany. Jednak oszustem, którego możesz użyć, jest dodanie do pliku hosts serwera, na którym działa, adres IP, który próbuje odwrócić.

W przypadku Sinatry często doświadczałem 10-sekundowych opóźnień. Ten fragment rozwiązał to za mnie.

Dodaj to w górnej części app.rbpliku

class Rack::Handler::WEBrick
    class << self
        alias_method :run_original, :run
    end
    def self.run(app, options={})
        options[:DoNotReverseLookup] = true
        run_original(app, options)
    end
end

Zobacz źródło

To jest stary wątek z pytaniami i odpowiedziami, który pomógł mi rozwiązać :DoNotReverseLookupproblem na lokalnej maszynie wirtualnej programowania i chciał dodać dodatkowe informacje. Ta strona internetowa wyjaśnia błąd regresji w rdzeniu Ruby, który doprowadził do pojawienia się tego problemu; nacisk jest mój; Krótko mówiąc, istnieje żądanie ściągnięcia GitHub dotyczące poprawki rdzenia Rubiego i miejmy nadzieję, że zostanie ono zatwierdzone i włączone do wkrótce wydanej wersji Rubiego:

Po kilku godzinach rozwiązywania problemów okazało się, że tak! Wygląda na to, że gdzieś w trakcie ewolucji standardowej biblioteki Ruby z 1.8.6 do 2.0.0, WEBrick nabył nową opcję konfiguracji, :DoNotReverseLookupktóra jest nildomyślnie ustawiona . Następnie, głęboko w trzewiach kodu przetwarzania żądań WEBrick, ustawia do_not_reverse_lookupflagę dla wystąpienia gniazda połączenia przychodzącego na wartość config[:DoNotReverseLookup]. Ponieważ ta wartość jest nilfałszywa, efekt jest taki sam, jak ustawienie jej na false, przesłaniając Socket.do_not_reverse_lookupflagę globalną . Tak więc, jeśli nie masz: DoNotReverseLookup => truew konfiguracji WEBrick odwrotne wyszukiwanie DNS będzie zawsze odbywać się dla każdego nowego połączenia, potencjalnie powodując poważne opóźnienia.

Związane z tym odkryciem jest żądanie ściągnięcia GitHub od autora, proponujące, jak naprawić problem w kodzie źródłowym Ruby WEBrick: Napraw błąd regresji w WEBrick's: implementacja opcji konfiguracji DoNotReverseLookup # 731

Rozwiązaniem przedstawionym w żądaniu jest zmiana wiersza 181 lib/webrick/server.rbz tego:

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

Do tego:

unless config[:DoNotReverseLookup].nil?

Udostępniam tutaj, jeśli ktoś natknie się na ten dobrze traktowany wątek pytań / odpowiedzi i jest zainteresowany postępem w rozwiązywaniu tego problemu w rdzeniu Ruby. Miejmy nadzieję, że to przyciąganie zostanie scalone lub podstawowa kwestia zostanie w jakiś sposób rozwiązana w następnym wydaniu Rubiego; może 2.1.6?

To jest bardzo późna odpowiedź, ale większość dnia spędziłem na debugowaniu tego właśnie problemu z Railsami działającymi na Vagrant. Zmiana wyszukiwania wstecznego DNS w rzeczywistości wcale nie poprawiła czasu żądań. Połączenie dwóch rzeczy spowodowało wczytanie mojej strony z ~ 20 sekund do ~ 3 sekund w trybie programistycznym:

Zamień WEBrick na kundel. Musiałem użyć wersji przedpremierowej lub nie mogłem zainstalować:

sudo gem install mongrel --pre

Następnie dodaj go do mojego Gemfile dla programistów:

group :test, :development do
  gem 'mongrel'
end

Uruchomiłem wtedy mój serwer w ten sposób:

rails server mongrel -e development

To trwało kilka sekund, 5 lub 6 sekund, ale nadal było strasznie wolno. To była wisienka na torcie - dodaj to również do Gemfile:

group :development do
  gem 'rails-dev-boost', :git => 'git://github.com/thedarkone/rails-dev-boost.git'
end

W przeglądarce DoNotReverseLookupRuby 1.8.x nie ma opcji. Rozwiązaniem jest umieszczenie:

Socket.do_not_reverse_lookup = true

gdzieś na początku twojego skryptu.

Źródło: WEBrick and Socket.do_not_reverse_lookup: A Tale in Two Acts

W mojej prawdopodobnie rzadkiej sytuacji zadziałało po opróżnieniu iptables, nie miało to żadnych skutków ubocznych, ponieważ nie miałem żadnych niestandardowych reguł (tylko domyślny Ubuntu zezwala na wszystko):

sudo iptables -F