Production cache

alesc · July 19, 2009, 8:49pm

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…

alesc · July 20, 2009, 1:52pm

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…

alesc · July 20, 2009, 11:07am

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

alesc · July 20, 2009, 3:43pm

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 Caching with Rails: An Overview — Ruby on Rails Guides e poi
eventualmente
ActionController::Caching
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

alesc · July 21, 2009, 10:32am

Paolo M. wrote:

Non ho mai fatto niente di particolarmente avanzato con il caching, perÃ²
leggi Caching with Rails: An Overview — Ruby on Rails Guides e poi
eventualmente
ActionController::Caching
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

alesc · July 21, 2009, 11:37am

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 Caching with Rails: An Overview — Ruby on Rails Guides e poi
eventualmente
ActionController::Caching
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…

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

alesc · July 21, 2009, 3:05pm

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!

alesc · July 21, 2009, 11:10am

Alessandro S. wrote:

Paolo M. wrote:

Non ho mai fatto niente di particolarmente avanzato con il caching, perÃ²
leggi Caching with Rails: An Overview — Ruby on Rails Guides e poi
eventualmente
ActionController::Caching
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…

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

alesc · July 30, 2009, 8:43am

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

alesc · July 29, 2009, 10:36am

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

alesc · July 30, 2009, 9:45am

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)