Production cache

Oggi ho perso 5 ore per risolvere un problema su clerk(per chi non lo
conosce www.clerk.it) ogni tanto mongrel mi restituiva una pagina
diversa da quella richiesta (le pagine sono identificate anche in base
alla url che identifica quale sottosito sto visualizzando).

Alla fine era colpa di:

–>>> config.cache_classes = true
---->>>> config.action_controller.consider_all_requests_local = false
config.action_controller.perform_caching = true
config.action_view.cache_template_loading = true

queste due righe facevano sì che invece di elaborare la richiesta rails
desse per scontato il risultato in base all’ultima chiamata al
controller…

Invertiti i valori e magia sistema multisito funzionante in production…

Paolo M. wrote:

Non mi è chiaro se ora hai le righe

config.cache_classes = false
config.action_controller.consider_all_requests_local = true

Le ho così

oppure hai messo a false le altre due opzioni di configurazione. Te lo
chiedo perché cache_classes a false obbliga rails a ricaricare tutte le
classi (modelli, viste, controller) ad ogni chiamata, rallentando non
poco il server. In pratica è la differenza principale tra il development
e il production mode.

Paolo

Mi accorgo della differenza di prestazioni ma non ho trovato altro modo
per risolvere…

Alessandro S. wrote:

Oggi ho perso 5 ore per risolvere un problema su clerk(per chi non lo
conosce www.clerk.it) ogni tanto mongrel mi restituiva una pagina
diversa da quella richiesta (le pagine sono identificate anche in base
alla url che identifica quale sottosito sto visualizzando).

Alla fine era colpa di:

–>>> config.cache_classes = true
---->>>> config.action_controller.consider_all_requests_local = false
config.action_controller.perform_caching = true
config.action_view.cache_template_loading = true

queste due righe facevano sì che invece di elaborare la richiesta rails
desse per scontato il risultato in base all’ultima chiamata al
controller…

Invertiti i valori e magia sistema multisito funzionante in production…

Non mi è chiaro se ora hai le righe

config.cache_classes = false
config.action_controller.consider_all_requests_local = true

oppure hai messo a false le altre due opzioni di configurazione. Te lo
chiedo perché cache_classes a false obbliga rails a ricaricare tutte le
classi (modelli, viste, controller) ad ogni chiamata, rallentando non
poco il server. In pratica è la differenza principale tra il development
e il production mode.

Paolo

Alessandro S. wrote:

Paolo M. wrote:

Non mi è chiaro se ora hai le righe

config.cache_classes = false
config.action_controller.consider_all_requests_local = true

Le ho così

oppure hai messo a false le altre due opzioni di configurazione. Te lo
chiedo perché cache_classes a false obbliga rails a ricaricare tutte le
classi (modelli, viste, controller) ad ogni chiamata, rallentando non
poco il server. In pratica è la differenza principale tra il development
e il production mode.

Paolo

Mi accorgo della differenza di prestazioni ma non ho trovato altro modo
per risolvere…

Non ho mai fatto niente di particolarmente avanzato con il caching, però
leggi http://guides.rubyonrails.org/caching_with_rails.html e poi
eventualmente
http://api.rubyonrails.org/classes/ActionController/Caching.html#M000469
nella cui sezione “Classes and Modules” ci sono i link alla
documentazione dei quattro moduli di caching. Sono Module
ActionController::Caching::Actions, Module
ActionController::Caching::Fragments, Module
ActionController::Caching::Pages e Module
ActionController::Caching::Sweeping.

Per curiosità , config.action_controller.perform_caching = false dovrebbe
disabilitare tutto il caching. Non aveva funzionato?

Paolo

Paolo M. wrote:

Non ho mai fatto niente di particolarmente avanzato con il caching, però
leggi http://guides.rubyonrails.org/caching_with_rails.html e poi
eventualmente
http://api.rubyonrails.org/classes/ActionController/Caching.html#M000469
nella cui sezione “Classes and Modules” ci sono i link alla
documentazione dei quattro moduli di caching. Sono Module
ActionController::Caching::Actions, Module
ActionController::Caching::Fragments, Module
ActionController::Caching::Pages e Module
ActionController::Caching::Sweeping.

Per curiosità , config.action_controller.perform_caching = false dovrebbe
disabilitare tutto il caching. Non aveva funzionato?

Paolo

Ora le leggo

No perform_caching non funziona

Problema interessante. Secondo me spiegando bene quel che ti succede
potresti destare dell’interesse nel forum inglese di rails
http://www.ruby-forum.com/forum/3

Sai, il fatto di dover andare in produzione ricaricando tutte le classi
ad ogni richiesta vuol dire che o è sbagliato Rails o c’è qualche
configurazione che ci sfugge. E se è sbagliato Rails, magari qualche
developer troverà il modo di sistemarlo.

Paolo

Alessandro S. wrote:

Alessandro S. wrote:

Paolo M. wrote:

Non ho mai fatto niente di particolarmente avanzato con il caching, però
leggi http://guides.rubyonrails.org/caching_with_rails.html e poi
eventualmente
http://api.rubyonrails.org/classes/ActionController/Caching.html#M000469
nella cui sezione “Classes and Modules” ci sono i link alla
documentazione dei quattro moduli di caching. Sono Module
ActionController::Caching::Actions, Module
ActionController::Caching::Fragments, Module
ActionController::Caching::Pages e Module
ActionController::Caching::Sweeping.

Per curiosità , config.action_controller.perform_caching = false dovrebbe
disabilitare tutto il caching. Non aveva funzionato?

Paolo

Ora le leggo

No perform_caching non funziona

Pare proprio che io non possa usare meccanismi di caching “base” dovrei
fare cache di singoli blocchi di codice/html per volta… impossibile
chiaramente… :confused:

(la cache ignora i parametri e non esegue i filter come autenticazione
etc… quindi su un gestionale non si può proprio fare…)

Paolo M. wrote:

Problema interessante. Secondo me spiegando bene quel che ti succede
potresti destare dell’interesse nel forum inglese di rails
http://www.ruby-forum.com/forum/3

Sai, il fatto di dover andare in produzione ricaricando tutte le classi
ad ogni richiesta vuol dire che o è sbagliato Rails o c’è qualche
configurazione che ci sfugge. E se è sbagliato Rails, magari qualche
developer troverà il modo di sistemarlo.

Paolo

ora posto!

Alessandro S. wrote:

Paolo M. wrote:

Non ho mai fatto niente di particolarmente avanzato con il caching, però
leggi http://guides.rubyonrails.org/caching_with_rails.html e poi
eventualmente
http://api.rubyonrails.org/classes/ActionController/Caching.html#M000469
nella cui sezione “Classes and Modules” ci sono i link alla
documentazione dei quattro moduli di caching. Sono Module
ActionController::Caching::Actions, Module
ActionController::Caching::Fragments, Module
ActionController::Caching::Pages e Module
ActionController::Caching::Sweeping.

Per curiosità , config.action_controller.perform_caching = false dovrebbe
disabilitare tutto il caching. Non aveva funzionato?

Paolo

Ora le leggo

No perform_caching non funziona

Pare proprio che io non possa usare meccanismi di caching “base” dovrei
fare cache di singoli blocchi di codice/html per volta… impossibile
chiaramente… :confused:

(la cache ignora i parametri e non esegue i filter come autenticazione
etc… quindi su un gestionale non si può proprio fare…)

Alessandro S. wrote:

Neanche su quello inglisc hanno trovato nulla… ora sono passato a
development direttamente (continuavano risposte cache anche con i
settaggi a false…)

Sì ho visto perché ho tenuto d’occhio il tuo post. Ci vorrebbe una bella
sessione di debug dentro le classi di Rails, per capire come mai il
caching avviene lo stesso. Per farlo tuttavia serve un bel po’ di
tempo.

A proposito, usi la 2.3.3 di Rails o una versione precedente? Hai
verificato che non dipenda anche da impostazioni di caching del browser
o dagli header inviati dall’eventuale web server davanti a mongrel?

Paolo

Alessandro S. wrote:

Paolo M. wrote:

Problema interessante. Secondo me spiegando bene quel che ti succede
potresti destare dell’interesse nel forum inglese di rails
http://www.ruby-forum.com/forum/3

Sai, il fatto di dover andare in produzione ricaricando tutte le classi
ad ogni richiesta vuol dire che o è sbagliato Rails o c’è qualche
configurazione che ci sfugge. E se è sbagliato Rails, magari qualche
developer troverà il modo di sistemarlo.

Paolo

ora posto!

Neanche su quello inglisc hanno trovato nulla… ora sono passato a
development direttamente (continuavano risposte cache anche con i
settaggi a false…)

Paolo M. wrote:

Alessandro S. wrote:

Neanche su quello inglisc hanno trovato nulla… ora sono passato a
development direttamente (continuavano risposte cache anche con i
settaggi a false…)

Sì ho visto perché ho tenuto d’occhio il tuo post. Ci vorrebbe una bella
sessione di debug dentro le classi di Rails, per capire come mai il
caching avviene lo stesso. Per farlo tuttavia serve un bel po’ di
tempo.

A proposito, usi la 2.3.3 di Rails o una versione precedente? Hai
verificato che non dipenda anche da impostazioni di caching del browser
o dagli header inviati dall’eventuale web server davanti a mongrel?

Paolo

Ho disattivato tutta la cache di apache e ho provato a chiedere come
fare a modificare questo :

<Proxy balancer://clerk_cluster>
BalancerMember http://localhost:3010
BalancerMember http://localhost:3011
BalancerMember http://localhost:3012
BalancerMember http://localhost:3013
BalancerMember http://localhost:3014

in qualcosa che riconosca il nome dominio (sostituire localhost con il
nome dominio in base alla richiesta in pratica), ma nessuno ha
risposto…
(http://groups.google.it/group/it.comp.www.server/browse_thread/thread/92f549f4eef00606/f8e2cb8bccb06241?hl=it&ie=UTF-8&q=BalancerMember#f8e2cb8bccb06241)

Anche se non penso sia questo il problema…

Qualche esperto di apache ne ha idea?

Uso la 2.3.3, e ho provato con 3 browser diversi (opera firfox e
seamonkey)

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs