Webrick è molto lento a rispondere. Come accelerarlo?

Ho un’applicazione Rails che sto utilizzando sul mio server. Quando vado su un desktop remoto e provo a caricare l’applicazione, il server impiega 3-4 minuti per rispondere con una semplice pagina HTML. Tuttavia, quando carico la pagina localmente sul server, la pagina si presenta in un secondo. Ho provato a eseguire il ping del server dal mio desktop remoto e il ping ha avuto successo in un ragionevole lasso di tempo.

Tutto sembra essere iniziato dopo aver installato il client di base di Oracle e SQLPLUS. Dovrei sospettare di Oracle? Qualcuno ha vissuto qualcosa di simile a questo?

Avere lo stesso problema qui (anche un anno dopo). Sotto linux devi fare quanto segue:

Cerca il file /usr/lib/ruby/1.9.1/webrick/config.rb e modificalo.

Sostituisci la linea

:DoNotReverseLookup => nil, 

con

 :DoNotReverseLookup => true, 

Riavvia webrick e funzionerà come un fascino 🙂

Aveva lo stesso problema. Per me, questo post ha tenuto la soluzione. Se sei su Ubuntu, ferma (o disinstalla) il avahi-daemon . service avahi-daemon stop arresta il demone.

Webrick ora si sente molto veloce.

Il problema ha un vecchio report in Rails Lighthouse , tuttavia, da allora Ruby-on-Rails ha spostato i propri ticket su github ; Un po ‘sfortunato che questo vecchio problema persiste ancora.

Tuttavia, avahi-daemon che se in realtà usi avahi-daemon per qualcosa, come trovare stampanti e scanner sulla tua rete, non funzionerà più.

Ho appena avuto lo stesso problema. Il

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

ha fatto il trucco anche per me. Nel caso in cui tu stia rubando sotto il rvm, ecco la strada da percorrere per:

 ~/.rvm/rubies/ruby-/lib/ruby//webrick/config.rb 

“Thin” è ora una big opzione per l’esecuzione sia localmente e su Heroku :

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

Sito Web: http://code.macournoyer.com/thin/

Puoi usarlo localmente inserendo il tuo Gemfile:

 gem "thin" 

… e poi esegui bundle e avvia il tuo server con thin start o rails s .

Aggiornamento su Heroku

Thin ora è considerato una ctriggers scelta per Heroku. Maggiori informazioni qui:

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

La loro raccomandazione:

Passa a un back-end web concorrente come Unicorn o Puma su JRuby, che consente al banco di gestire la propria coda di richieste ed evitare il blocco di richieste lunghe.

Ho avuto un problema vagamente simile che si è manifestato durante l’accesso a un server WEBrick tramite VPN. Le richieste richiederebbero molto tempo, in gran parte senza che nulla avvenga sul cavo. Dato che né il mongrel né le gemme thin funzionato con Ruby1.9 su Windows e non c’era alcun modo in cui mi stavo coinvolgendo nella compilazione di materiale proveniente dal codice sorgente, dovevo attenermi a WEBrick.

La correzione era di impostare il parametro di configurazione DoNotReverseLookup su true , durante la creazione del server WEBrick:

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

Puoi usare Apache o installare Thin . Nel tuo Gemfile: gem 'thin'

Oppure è ansible controllare l’elenco dei server Web per le guide .

Stavo cercando di farlo con webrick alla 1.8.7 e non riuscivo a trovare la configurazione da cambiare. Tuttavia, un trucco che puoi usare è quello di aggiungere al file hosts del server che sta eseguendo webrick l’indirizzo IP che sta cercando di annullare la ricerca ..

Ho subito ritardi di 10 secondi frequenti con Sinatra. Questo frammento ha risolto per me.

Aggiungi questo nella parte superiore del tuo file app.rb

 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 

Vedi sorgente

Questa è una vecchia discussione di domande e risposte che mi ha aiutato a risolvere il problema :DoNotReverseLookup su una macchina virtuale di sviluppo locale e volevo aggiungere ulteriori informazioni. Questa pagina web spiega l’errore di regressione nel core di Ruby che porta a questo problema apparire per alcuni; l’enfasi è mia; a parte un po ‘di tutto questo c’è una richiesta di pull GitHub per una correzione del core di Ruby a questo e speriamo che venga approvata e unita in una versione di Isotta di Ruby:

Dopo alcune ore di risoluzione dei problemi, si è scoperto che lo era! Apparentemente, da qualche parte lungo l’evoluzione della lib standard di Ruby da 1.8.6 a 2.0.0, WEBrick ha acquisito una nuova opzione di configurazione :DoNotReverseLookup che è impostata su nil per impostazione predefinita. Quindi, nel profondo del coraggio del codice di elaborazione delle richieste di WEBrick, imposta il flag do_not_reverse_lookup del socket di connessione in ingresso sul valore di config[:DoNotReverseLookup] . Poiché questo valore è nil , che è falsy, l’effetto è lo stesso di impostarlo su false , sovrascrivendo il flag globale Socket.do_not_reverse_lookup . Quindi, a meno che tu non abbia: DoNotReverseLookup => true nella tua configurazione di WEBrick, la ricerca DNS inversa avverrà sempre per ogni nuova connessione, causando potenzialmente una grave latenza.

Relativo a questa scoperta è una richiesta di pull GitHub dell’autore che propone come riparare il problema nel codice sorgente di Ruby WEBrick: Correzione del bug di regressione in WEBrick: Implementazione opzione di configurazione DoNotReverseLookup # 731

La soluzione come delineata nella richiesta è di modificare la riga 181 in lib/webrick/server.rb da questo:

 sock.do_not_reverse_lookup = config[:DoNotReverseLookup] 

A questa:

 unless config[:DoNotReverseLookup].nil? 

Condividendo qui se qualcuno si imbatte in questa discussione di domande / risposte ben considerata e sono interessati ai progressi nella risoluzione di questo problema nel nucleo di Ruby. Speriamo che questa attrazione venga unita o che il problema sottostante sia trattato in qualche modo nella prossima versione di Ruby; forse 2.1.6?

Questa è una risposta molto tarda, ma ho passato buona parte della giornata a risolvere questo problema con Rails in esecuzione su Vagrant. La modifica della ricerca DNS inversa non ha effettivamente migliorato i tempi di richiesta. Una combinazione di due cose ha richiesto il caricamento della mia pagina da ~ 20 secondi a ~ 3 secondi in modalità sviluppo:

Sostituisci WEBrick con mongrel. Ho dovuto usare la versione preliminare o non installare:

 sudo gem install mongrel --pre 

Quindi aggiungilo al mio Gemfile per dev:

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

Iniziato il mio server in questo modo quindi:

 rails server mongrel -e development 

Che ha tagliato alcuni secondi, 5 o 6 secondi, ma era ancora terribilmente lento. Questa è stata la ciliegina sulla torta – aggiungi questo anche al Gemfile:

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

Non esiste DoNotReverseLookup opzione DoNotReverseLookup in ruby ​​1.8.x webrick. La soluzione è mettere:

 Socket.do_not_reverse_lookup = true 

da qualche parte all’inizio del tuo script.

Fonte: WEBrick e Socket.do_not_reverse_lookup: Un racconto in due atti

Nella mia situazione probabilmente rara, ha funzionato dopo aver scaricato il mio iptables, questo non ha avuto effetti collaterali perché non avevo alcuna regola personalizzata (solo l’Ubuntu predefinito consente tutti):

 sudo iptables -F