sempre la prima richiesta (di una sessione di lavoro) alla mia app Rails è in ritardo. Passare alla modalità di produzione non aiuta.La prima richiesta dell'app Rails è molto lenta
Io uso il meticcio e le altre richieste vengono gestite con velocità accettabile.
Come posso renderlo più veloce?
saluti
Se pubblichi il contenuto del registro mentre viene elaborata la prima richiesta, forse possiamo capire cosa lo rende così lento. Ad esempio, questo è il mio registro come il primo utente accede al sito
Booting Mongrel (use 'script/server webrick' to force WEBrick)
Rails 2.1.0 application starting on http://0.0.0.0:3000
Debugger enabled
Call with -d to detach
Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
/usr/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/mime_type.rb:66: warning: already initialized constant CSV
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart).
** Rails signals registered. HUP => reload (without restart). It might not work well.
** Mongrel 1.1.5 available at 0.0.0.0:3000
** Use CTRL-C to stop.
Processing SessionsController#new (for 127.0.0.1 at 2009-05-26 12:26:00) [GET]
Session ID: de2acf074759026e1ed6205724f547a9
Parameters: {"action"=>"new", "controller"=>"sessions"}
Rendering sessions/new
Completed in 0.00587 (170 reqs/sec) | Rendering: 0.00298 (50%) | DB: 0.00092 (15%) | 200 OK [http://localhost/]
Credo 170 reqs/sec è bene per la nostra applicazione, ma altri possono trovare che rallentano. È possibile vedere dalle statistiche che le rotaie forniscono che la metà del tempo richiesto viene speso per il rendering della risposta, in questo caso la generazione dell'HTML per la schermata di accesso. Se questa richiesta richiedeva molto tempo, il mio primo punto di riferimento sarebbero le viste e gli helper associati alla schermata di accesso.
Se si dispone di un sistema che impiega molto tempo per inizializzarsi sulla prima richiesta, allora perché non essere subdolo e scrivere il proprio programma di avvio che prima esegue le rotaie e quindi invia una richiesta falsa in via arricciatura. In questo modo i tuoi utenti non vedranno mai il problema.
Chris
Può essere la stessa ragione le nostre applicazioni di prendere un lungo periodo di tempo la prima volta che li dà il via a Websphere.
WAS deve eseguire molto lavoro iniziale per configurare i contenitori quando viene installata una nuova versione dell'applicazione (o WAS viene riavviato).
La soluzione che abbiamo usato è stata quella di modificare gli script di installazione e gli script di avvio di WAS in modo che fossero automaticamente sfogliati nell'applicazione (pagina principale e altre pagine selezionate) non appena era in esecuzione. In quel modo, il primo vero accesso ad esso era a tutta velocità.
Non ho idea di come farlo con Ruby o anche se è possibile. Dovrai capirlo.
È possibile - è possibile utilizzare uno script semplice per richiedere una pagina da tutte le app di guide utilizzando curl/wget per ottenere lo stesso effetto. – Petesh
immagino che si sta utilizzando Ferret per la ricerca full-text? Potrebbe essere che la connessione del furetto impiega un po 'di tempo per inizializzarsi? Quando controllo il tuo log, sembra che sia il db che la vista richiedano una quantità di tempo normale, ma il totale è ancora di 10 secondi. Quindi devo essere qualcos'altro per cui immagino che Ferret potrebbe essere il problema.
Può essere perché siete:
che richiede e il caricamento di un certo numero di plugin e gemme
effettuare la connessione ad un servizio esterno (quindi la memorizzazione nella cache)
memorizzare nella cache le proprie pagine e solo dopo la prima richiesta si verifica a meno che non sia a "riscaldare" la cache
Ciascuno di questi aumenterà inevitabilmente il tempo di risposta della prima richiesta.
Forse è necessario regolare la variabile PassengerPoolIdleTime in apache conf. Impostalo su 0 per non interrompere mai il processo delle tue guide.
Grazie per il tuo suggerimento. Ecco il mio file di registro: http://pastie.org/private/ih2mpcmjpofp5jmfsvw A volte, dura molto più di 1600 ms per rispondere alla mia richiesta. Davvero non ne ho la minima idea ... – Stefan
Quale versione di rail usi? Completato in 10367ms (Visualizza: 1572, DB: 450) | 200 OK [http: // localhost/search? Search = stefan +] Sembra che occorrano 10 secondi per rispondere alla prima richiesta. Immagino che cercare di nuovo la stessa query "stefan" sia molto più veloce? Quanto ci vuole per trovare un altro record? Infine, quanto tempo ci vuole per cercare un record inesistente? –