Vai al contenuto

Guida completa Drupal

Prestazioni, cache e risorse in Drupal

In breve: Tempi di risposta, cache, query, processi, memoria e carico server. Questa guida riunisce i casi che prima erano distribuiti in trenta URL molto simili e li organizza in un unico percorso diagnostico verificabile.

Ambito e componenti da controllare

Il sintomo visibile è soltanto il punto di partenza. Prima di modificare Drupal, separa applicazione, estensioni, tema, database, cache, web server e servizi esterni. Cambia una variabile per volta e conserva sempre l’evidenza che conferma o esclude un livello.

Sintomi ed evidenze da raccogliere

Sintomo Prima evidenza utile
Sito lento Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Contenuti vecchi o non aggiornati Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Consumo elevato di CPU o memoria Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Timeout intermittenti Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Rallentamenti sotto carico Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.

Diagnosi per componente

Ogni componente può produrre sintomi simili. Le schede seguenti indicano cosa significa ciascun caso e quale prova raccogliere prima della correzione.

Render cache

Nel contesto di Drupal, render cache partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.

Sito lento

Quando render cache rende il sito lento, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Contenuti vecchi o non aggiornati

Quando render cache mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Consumo elevato di CPU o memoria

Quando render cache satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Timeout intermittenti

Quando render cache genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Rallentamenti sotto carico

Quando render cache peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Dynamic Page Cache

Nel contesto di Drupal, Dynamic Page Cache partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.

Sito lento

Quando Dynamic Page Cache rende il sito lento, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Contenuti vecchi o non aggiornati

Quando Dynamic Page Cache mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Consumo elevato di CPU o memoria

Quando Dynamic Page Cache satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Timeout intermittenti

Quando Dynamic Page Cache genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Rallentamenti sotto carico

Quando Dynamic Page Cache peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

BigPipe

Nel contesto di Drupal, BigPipe partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.

Sito lento

Quando BigPipe rende il sito lento, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Contenuti vecchi o non aggiornati

Quando BigPipe mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Consumo elevato di CPU o memoria

Quando BigPipe satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Timeout intermittenti

Quando BigPipe genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Rallentamenti sotto carico

Quando BigPipe peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Il database

Nel contesto di Drupal, il database partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.

Sito lento

Quando il database rende il sito lento, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Contenuti vecchi o non aggiornati

Quando il database mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Consumo elevato di CPU o memoria

Quando il database satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Timeout intermittenti

Quando il database genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Rallentamenti sotto carico

Quando il database peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

PHP e memoria

Nel contesto di Drupal, PHP e memoria partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.

Sito lento

Quando PHP e memoria rende il sito lento, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Contenuti vecchi o non aggiornati

Quando PHP e memoria mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Consumo elevato di CPU o memoria

Quando PHP e memoria satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Timeout intermittenti

Quando PHP e memoria genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Rallentamenti sotto carico

Quando PHP e memoria peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Reverse proxy e CDN

Nel contesto di Drupal, reverse proxy e CDN partecipa a un flusso più ampio. Assistenza Drupal per errori, Composer, Drush, moduli, temi, cache, configurazione, sicurezza e migrazioni. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nell’area amministrativa e i report di stato di Drupal, nei processi pianificati e nei servizi collegati.

Sito lento

Quando reverse proxy e CDN rende il sito lento, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Contenuti vecchi o non aggiornati

Quando reverse proxy e CDN mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Consumo elevato di CPU o memoria

Quando reverse proxy e CDN satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Timeout intermittenti

Quando reverse proxy e CDN genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Rallentamenti sotto carico

Quando reverse proxy e CDN peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Drupal conviene prima misurare separatamente tempo di risposta, query, processi, memoria, cache e dipendenze esterne invece di applicare ottimizzazioni indiscriminate. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Percorso diagnostico in ordine

Esegui i controlli dal meno invasivo al più profondo. Un tentativo è utile solo se ha un risultato atteso, produce un’evidenza e può essere annullato.

  1. Misurare ttfb, tempo totale e query su più pagine

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  2. Confrontare utenti anonimi e autenticati

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  3. Controllare processi, cron, code e attività lunghe

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  4. Analizzare cache hit, invalidazioni e oggetti troppo grandi

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  5. Verificare lentezza del database e servizi esterni

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  6. Ripetere i test dopo una sola modifica alla volta

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

Strumenti e percorsi utili in Drupal

  • Esegui vendor/bin/drush status dalla root corretta per registrare versione, database e percorso dei file.
  • Controlla i messaggi recenti con gli strumenti di report o vendor/bin/drush watchdog:show --count=50.
  • Usa vendor/bin/drush cache:rebuild solo come test mirato: una cache ricostruita non corregge codice, dati o dipendenze errati.
Attenzione: comandi, percorsi e nomi dei menu cambiano tra versioni e ambienti. Verifica sempre la documentazione della versione installata e non eseguire comandi distruttivi senza backup.

Verifica finale e rollback

Il ritorno della pagina non basta a chiudere l’intervento. Ripeti il caso iniziale, un caso di controllo e i flussi collegati; poi verifica che non siano comparsi nuovi errori.

  • render cache nel caso che generava il problema e in un secondo caso di controllo
  • frontend e area amministrativa con utenti e permessi differenti
  • salvataggio dei dati e assenza di nuovi errori nei log
  • email, attività pianificate, API, code o callback coinvolte
  • cache e CDN dopo la riattivazione
  • prestazioni, consumo risorse e stabilità per un intervallo adeguato
  • backup aggiornato e documentazione della modifica

Riferimenti ufficiali

I percorsi e i comandi possono cambiare tra versioni. Prima di intervenire, confronta la procedura con la documentazione della versione installata e conserva un rollback verificato.

Domande frequenti

Da quale controllo partire per prestazioni, cache e risorse in Drupal?

Parti da un caso riproducibile e dal log registrato nello stesso orario. Versioni, ultima modifica, URL, utente e risultato atteso permettono di distinguere un errore applicativo da cache, infrastruttura o servizi esterni.

È sufficiente svuotare la cache?

No. La cache è un livello da verificare, ma non corregge file mancanti, dipendenze incompatibili, dati incoerenti o configurazioni errate. Usala come test e annota quale livello ha restituito la risposta.

Quando serve un ambiente di staging?

Quando la correzione può influire su utenti, ordini, contenuti, permessi o configurazioni. Lo staging deve rappresentare il caso reale senza esporre dati personali e deve avere un piano di riallineamento con la produzione.

Quali informazioni preparare prima di chiedere assistenza?

Prepara URL, messaggio, orario, versione di Drupal, versione PHP e database, modifiche recenti, accessi disponibili e un estratto pertinente dei log. Non inviare password nel primo messaggio.

Quando è preferibile un rollback?

Quando il ripristino del servizio è prioritario e la modifica può essere annullata senza perdere dati recenti. Prima confronta file e database del backup con lo stato corrente e conserva separatamente ordini, utenti o contenuti creati dopo la copia.

Serve una diagnosi sul tuo sito?

Se il problema riguarda un’installazione reale, prepara versione, URL, orario, modifiche recenti e log pertinenti.

Assistenza Drupal Invia i dettagli del problema