Webrick è molto lento a rispondere. Come velocizzarlo?

Ho un'applicazione Rails che sto eseguendo sul mio server. Quando vado su un desktop remoto e tento di caricare l'applicazione, il server impiega 3-4 minuti buoni per rispondere con una semplice pagina HTML. Tuttavia, quando carico la pagina localmente sul server, la pagina viene visualizzata in un secondo. Ho provato a eseguire il ping del server dal mio desktop remoto e i ping hanno avuto successo in un ragionevole lasso di tempo.

Sembra che tutto sia iniziato dopo aver installato il client di base di Oracle e SQLPLUS. Dovrei sospettare Oracle? Qualcuno ha sperimentato qualcosa di simile a questo?

Avendo 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à a meraviglia :)

Ho avuto lo stesso problema. Per me, questo post rappresentava la soluzione. Se sei su Ubuntu, interrompi (o disinstalla) il file avahi-daemon. service avahi-daemon stoparresta il demone.

Webrick ora si sente molto veloce.

Il problema ha un'estensione vecchio rapporto in Rails Lighthouse , tuttavia, Ruby-on-Rails ha spostato i propri biglietti su GitHub ; Un po 'sfortunato che questo vecchio problema persista ancora.

Tieni presente però che se usi effettivamente avahi-daemonqualcosa, 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 eseguendo ruby ​​sotto il rvm, ecco il percorso da seguire:

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

"Thin" è ora un'ottima opzione per eseguire entrambi in locale e su Heroku:

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 starto rails s.

Aggiornamento su Heroku

Thin è ora considerata una cattiva 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 backend web simultaneo come Unicorn o Puma su JRuby, che consente al banco prova di gestire la propria coda di richieste ed evitare il blocco su richieste lunghe.

Ho avuto un problema vagamente simile che si è manifestato durante l'accesso a un server WEBrick tramite una VPN. Le richieste richiederebbero molto tempo, la maggior parte del quale non accade nulla in rete. Dal momento che né mongrelné thingems funzionavano con Ruby1.9 su Windows e non c'era modo di farmi coinvolgere nella compilazione di cose dal sorgente, dovevo restare con WEBrick.

La soluzione era impostare il parametro di configurazione DoNotReverseLookupsu true, durante la creazione del server WEBrick:

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

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

Inoltre puoi controllare l'elenco dei web server per i binari .

Stavo cercando di farlo con webrick sulla 1.8.7 e non sono riuscito a trovare la configurazione da modificare. Tuttavia, un trucco che puoi usare è aggiungere al file hosts del server su cui è in esecuzione webrick l'indirizzo IP che sta cercando di invertire la ricerca.

Ho riscontrato spesso ritardi di 10 secondi con Sinatra. Questo frammento lo ha risolto per me.

Aggiungi questo nella parte superiore del app.rbfile

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 fonte

Questo è un vecchio thread di domande e risposte che mi ha aiutato a risolvere il :DoNotReverseLookupproblema 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 ha portato alla comparsa di questo problema per alcuni; l'enfasi è mia; la cosa più lunga è che c'è una richiesta pull di GitHub per una correzione del core Ruby a questo e si spera che venga approvata e fusa in una versione presto di Ruby:

Dopo alcune ore di risoluzione dei problemi, si è scoperto che lo era! Apparentemente, da qualche parte lungo l'evoluzione della libreria standard di Ruby dalla 1.8.6 alla 2.0.0, WEBrick ha acquisito una nuova opzione di configurazione :DoNotReverseLookupimpostata per nilimpostazione predefinita. Quindi, nel profondo del codice di elaborazione delle richieste di WEBrick, imposta il do_not_reverse_lookupflag sull'istanza del socket di connessione in entrata sul valore di config[:DoNotReverseLookup]. Poiché questo valore è nil, che è falso, l'effetto è lo stesso dell'impostazione su false, sovrascrivendo il Socket.do_not_reverse_lookupflag globale . Quindi, a meno che tu non abbia: DoNotReverseLookup => truenella configurazione WEBrick, la ricerca DNS inversa avverrà sempre per ogni nuova connessione, causando potenzialmente una grave latenza.

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

La soluzione come delineata nella richiesta è cambiare la riga 181 lib/webrick/server.rbda questa:

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

A questa:

unless config[:DoNotReverseLookup].nil?

Condivido qui se qualcuno si imbatte in questo thread di domande / risposte ben considerato e sono interessati ai progressi nella risoluzione di questo problema in Ruby core. Si spera che questo pull venga unito o che il problema sottostante venga affrontato 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 correggere questo problema con Rails in esecuzione su Vagrant. La modifica della ricerca DNS inversa non ha effettivamente migliorato affatto i tempi di richiesta. Una combinazione di due cose ha portato il caricamento della mia pagina da ~ 20 secondi a ~ 3 secondi in modalità sviluppo:

Sostituisci WEBrick con bastardo. Ho dovuto usare la versione prerelease o non si installava:

sudo gem install mongrel --pre

Quindi aggiungilo al mio Gemfile per dev:

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

Allora ho avviato il mio server in questo modo:

rails server mongrel -e development

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

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

Non ci sono DoNotReverseLookupopzioni 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: A Tale in Two Acts

Nella mia situazione probabilmente rara, ha funzionato dopo aver svuotato il mio iptables, questo non ha avuto effetti collaterali perché non avevo regole personalizzate (solo l'impostazione predefinita di Ubuntu consente tutto):

sudo iptables -F