Webrick bardzo wolno reaguje. Jak to przyspieszyć?

88

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?

Prof. Falken
źródło
2
Może teraz należy to przenieść do błędu serwera?
Prof. Falken,
Nie ma takiej potrzeby, można to rozwiązać, po prostu modyfikując linię w pliku konfiguracyjnym
Mosty Mostacho
2
@AmigableClarkKant Webrick jest bardziej narzędziem programistycznym, więc wydaje się, że lepiej pozostać przy SO.
David
dobra, i cały czas przypisywałem problem vmware, pal w piekle webrick :(
prusswan

Odpowiedzi:

139

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 :)

Mosty Mostacho
źródło
21
Pracowałem! Miałem problemy z powolnym działaniem Webricka podczas udostępniania statycznej zawartości z innego komputera w naszej sieci lokalnej. To rozwiązało problem. Jedyną różnicą było to, że config.rb znajdował się w: ~ / .rvm / rubies / ruby-1.9.2-p180 / lib / ruby ​​/ 1.9.1 / webrick / config.rb - ponieważ używamy RVM.
Slobodan Kovacevic
btw, nie miałem tego klucza, więc po prostu go dodałem i zadziałało
ecoologic
gdzie to dodałeś? która sekcja?
Abe Petrillo
Powinien znajdować się w sekcji Ogólne zgodnie z ruby-doc.org/stdlib/libdoc/webrick/rdoc/classes/WEBrick/… .
David Grayson
10
Wersja Rubiego, którą mam, to ruby-1.8.7-p330 i nie wydaje się, aby zawierała opcję DoNotReverseLookup. Ciąg „DoNotReverseLookup” nie pojawia się w config.rb webrick ani nigdzie w ~ / .rvm / rubies / ruby-1.8.7-p330 / lib / ruby ​​/ 1.8. Czy jest jakiś fajny sposób na naprawienie tego problemu w Ruby-1.8.7-p330?
David Grayson
36

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.

Prof. Falken
źródło
1
Dziękuję bardzo!! Rozwiązało mój problem na Ubuntu 11.04 / 11.10 / 12.04
SMMousavi
1
Cóż, ta odpowiedź wydaje się być dla mnie niedocenionym bohaterem!
PCoder
1
To też zrobiło to dla mnie. Uruchamianie aplikacji
STAREJ
1
to rozwiązanie w rzeczywistości stwarza mi kłopoty, ponieważ zatrzymanie powoduje szaleństwo usług sieciowych! sprawdź następujący adres URL forums.fedoraforum.org/showthread.php?t=124837
Isaiyavan Babu Karan
23

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
Kjellski
źródło
1
Dzięki! Zanim znalazłem twoją odpowiedź, przeszukałem .rvm i nie znalazłem webrick, zmieniłem / usr / lib i to nie pomogło. To zadziałało.
B Seven
@KenBarber Jestem pewien, że to nie jest dobry kierunek, ale aby mieć ładny i mały cykl rozwojowy, wystarczy wprowadzić tę modyfikację do lokalnej instalacji RVM. A swoją drogą, to po prostu Twój profil użytkowników, nie będzie przeszkadzało nikomu indziej ...
Kjellski
1
@Kjellski być może masz rację, ale nie utrzymuje się ono podczas uaktualnień ani nie jest rozwiązaniem, które możesz łatwo przekazać innym twórcom. Być może łatka małpa na Railsach w tym przypadku lepiej wzrusza ramionami . W każdym razie zostało to naprawione teraz: github.com/rails/rails/commit/ ...
Ken Barber
15

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

Na Heroku: https://devcenter.heroku.com/articles/rails3#webserver

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

Jamon Holmgren
źródło
Idealne rozwiązanie, nie zmieniając kodów ani niczego w systemie.
Fernando Kosh,
Okazuje się, że Sinatra automatycznie używa cienkiej zamiast cegły sieciowej, jeśli jest zainstalowana. Wszystko co musiałem zrobić to gem install thin. Zobacz sinatrarb.com/intro.html. Zaleca się również uruchomienie gem install thin, które Sinatra odbierze, jeśli będzie dostępny. EDYCJA: Drastyczna poprawa wydajności. Od 1,3 do 0,05 s.
GuiSim
6

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, ...}
mackenir
źródło
5

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

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

Uladz Kha
źródło
2

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

patrickdavey
źródło
Świetny. Jest to lepsze niż edycja jakiegoś pliku cegły, który wymaga zmiany po każdej aktualizacji.
Petr
W moim przypadku wpisem do dodania (dla gościa Linuksa działającego webrick) byłby adres IP hosta Windows
prusswan
2

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

neoneye
źródło
1

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?

Giacomo1968
źródło
0

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
AlienWebguy
źródło
0

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
Nabil Kadimi
źródło