Strategie di svuotamento della cache per il salvataggio della memoria per siti di grandi dimensioni?

Uno dei miei siti Drupal 7 ha migliaia di campi, un mucchio di tipi di contenuto, più di 25 visualizzazioni e centinaia (che presto saranno migliaia) di tipi di profilo. Per questo motivo, sto usando una patch di base che memorizza meglio nella cache le informazioni sul campo dell'entità (http://drupal.org/node/1040790) e la versione -dev di Views che memorizza meglio nella cache le visualizzazioni per display (invece di avere un ENORME riga della cache delle viste con tutti i dati delle viste al suo interno).

Ciò ha aiutato la maggior parte delle pagine del sito a caricarsi con 20-30 MB di RAM utilizzati, anziché 160 MB + (invece di recuperare le righe della tabella cache_ * per campi e viste che erano 10 MB +, le patch aiutano a mantenere i dati cache_ * molto più efficienti).

Ciò introduce un problema, tuttavia, in quanto la ricostruzione della cache richiede molto tempo . Di solito più di un minuto o due. E durante questo periodo, Drupal semplicemente non caricherà alcuna pagina (poiché le cache che sta cercando di leggere non sono ancora state costruite, altre richieste devono attendere).

Durante i cicli a basso traffico, questo non è un grosso problema; un centinaio di utenti dovranno semplicemente attendere un minuto prima che la pagina venga caricata. Ma durante i cicli ad alto traffico, il server Apache inizia a impazzire, con oltre 40 carichi di CPU, e la memoria si riempie rapidamente perché tutti i thread di lavoro rimangono in attesa e massimizzano la memoria, causando lo scambio. È una specie di spirale della morte. Un riavvio di httpd chiarirà le cose, ma ci vogliono 5-10 minuti perché le cose tornino alla normalità.

Il mio obiettivo è farlo in modo che la pulizia della cache non metta in ginocchio il sito. Per uno, se uso le singole funzioni di svuotamento della cache di admin_menu (come "CSS e JS", quindi "Menu", quindi "Registro temi", ecc.), Le cose procedono senza intoppi finché non premo l'opzione "Pagina e altro". Questo è quando la cache delle viste viene ripristinata (un'operazione molto intensa della CPU e del database con il numero di viste che devono essere memorizzate nella cache), e quando viene ripristinata la cache delle informazioni sul campo (che è anche intensiva della CPU e del database su questo sito).

Quindi ... le mie domande / idee:

• Utilizzando drush e / o altri script di shell, è possibile per me cancellare le cache in un modo più intelligente di "distruggere tutte le cache contemporaneamente e sperare in una ricostruzione pulita"?
• Posso bloccare le richieste http mentre si sta verificando la cancellazione della cache in modo che apache non venga ostruito da un sacco di richieste di timbratura della cache?
• Se riesco a cancellare le cache al di fuori della richiesta httpd di Drupal / normale, potrei presumibilmente impostare un memory_limit PHP più elevato per l'operazione di cancellazione della cache e ripristinare il mio memory_limit universale (ora impostato su 256 MB, nel caso in cui un singolo thread httpd debba cancellare le cache ...).

Fondamentalmente: esiste un modo intelligente e grazioso per cancellare tutte le cache con Drupal oltre a fare semplicemente clic sul pulsante nell'interfaccia utente o utilizzare drush cc all?

[ Modifica per chiarimenti : il problema principale che ho sono le ricostruzioni della cache , che (a) richiedono un po 'di tempo e (b) bloccano tutte le altre richieste fino al completamento delle ricostruzioni. Vorrei trovare un modo per farlo in modo che le ricostruzioni non siano altrettanto mortali durante i periodi di traffico intenso.]

Esiste un modo intelligente e grazioso per cancellare tutte le cache con Drupal oltre a fare semplicemente clic sul pulsante nell'interfaccia utente o utilizzare drush cc all?

Il modulo di azioni della cache lo fa. Dipende dalla regola. Ad esempio, è possibile impostare una regola per cancellare una vista specifica quando un nodo di tipo "x" è stato aggiunto o aggiornato. Consulta i documenti per maggiori dettagli.

Dai anche un'occhiata al grazioso modulo cache : non l'ho ancora provato ma sembra interessante.

Il problema principale è che stai usando MySQL per archiviare i dati della cache - per i siti a carico elevato questa è una soluzione molto inefficace.

Consiglio invece di usare Memcache . Ciò aumenterà notevolmente le prestazioni del sistema cache e offrirà 2 grandi vantaggi:

1. Memcache è molto più veloce per le operazioni di lettura e scrittura che MySQL - tutte le operazioni della cache (e la ricostruzione completa della cache) funzioneranno più velocemente.
2. Poiché i dati della cache non sono più memorizzati nel DB, la cancellazione della cache non bloccherà altre query MySQL.

Ecco un esempio di configurazione di Memcache per Drupal 7.

Utilizzando drush e / o altri script di shell, è possibile per me cancellare le cache in un modo più intelligente di "distruggere tutte le cache contemporaneamente e sperare in una ricostruzione pulita"?

Se non vuoi distruggere tutte le cache, usa: drush cc type_of_cacheper cancellarne una specifica o definirne una tua.

In alternativa, cancellare manualmente tutte le tabelle simili a cache, ad es

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v 

Se stai usando memcached (sintassi di Bash), prova:

pgrep memcached && echo flush_all > /dev/tcp/127.0.0.1/11211

Posso bloccare le richieste http mentre si sta verificando la cancellazione della cache in modo che apache non venga ostruito da un sacco di richieste di timbratura della cache?

Abilita la modalità di manutenzione ( drush -y vset maintenance_mode 1) per impedire alle persone di accedere al sito. Oppure configura il front-end per reindirizzare altrove (ad esempio in Vernice, reindirizzare in Apache o in modifica .htaccess).

Se riesco a cancellare le cache al di fuori della richiesta httpd di Drupal / normale, potrei presumibilmente impostare un PHP più elevato memory_limitper l'operazione di cancellazione della cache e ripristinare il mio universale memory_limit(ora impostato su 256 MB, nel caso in cui un singolo thread httpd debba cancellare le cache. .).

La cancellazione della cache non richiede più memoria, ma la ricostruzione della cache dopo la cancellazione richiederà più tempo. Puoi sempre riscaldare le cache eseguendo cron o aprendo qualsiasi pagina, ad es

time php -n -d memory_limit=-1 time $(which drush) cc registry
PHP_OPTIONS='-d memory_limit="2G"' drush cron
php -d memory_limit=1G ./scripts/drupal.sh http://localhost/

^{Specifica -ndi ignorare l' php.inielaborazione che può inoltre velocizzare il processo di svuotamento della cache.}

C'è potenzialmente un costo monetario, ma potresti usare una configurazione del server di cache come Varnish. Il lato positivo è che Varnish servirà il tuo sito mentre la cache viene svuotata sul server di produzione, senza che l'utente sia più saggio.

Il rovescio della medaglia: a seconda di quanti secondi / minuti di inattività del server di produzione rispetto alle impostazioni di timeout VCL, Varnish potrebbe aggiornarsi durante quel periodo e vedrai una schermata di errore Varnish 503.

Ma questo approccio insieme a Redis o Memcache può aiutare.