Guida completa Magento e Adobe Commerce
Prestazioni, cache e risorse in Magento e Adobe Commerce
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 Magento e Adobe Commerce, 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.
Varnish e cache
Nel contesto di Magento e Adobe Commerce, Varnish e cache partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.
Sito lento
Quando Varnish e cache rende il sito lento, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 Varnish e cache mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 Varnish e cache satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 Varnish e cache genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 Varnish e cache peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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.
Redis
Nel contesto di Magento e Adobe Commerce, Redis partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.
Sito lento
Quando Redis rende il sito lento, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 Redis mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 Redis satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 Redis genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 Redis peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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.
Gli indexer
Nel contesto di Magento e Adobe Commerce, gli indexer partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.
Sito lento
Quando gli indexer rende il sito lento, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 gli indexer mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 gli indexer satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 gli indexer genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 gli indexer peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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.
Cron
Nel contesto di Magento e Adobe Commerce, cron partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.
Sito lento
Quando cron rende il sito lento, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 cron mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 cron satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 cron genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 cron peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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.
OpenSearch
Nel contesto di Magento e Adobe Commerce, OpenSearch partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.
Sito lento
Quando OpenSearch rende il sito lento, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 OpenSearch mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 OpenSearch satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 OpenSearch genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 OpenSearch peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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.
Database e query
Nel contesto di Magento e Adobe Commerce, database e query partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.
Sito lento
Quando database e query rende il sito lento, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 database e query mostra contenuti vecchi o non aggiornati, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 database e query satura CPU o memoria, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 database e query genera timeout intermittenti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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 database e query peggiora soltanto sotto carico, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 Magento
- Esegui
bin/magento --versionebin/magento deploy:mode:showper registrare versione e modalità. - Controlla
var/log/,var/report/e i log dei servizi collegati nello stesso timestamp della richiesta. - Verifica in modo mirato
bin/magento cache:status,bin/magento indexer:statuse lo stato dei cron.
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.
- Varnish e 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 Magento?
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 Magento e Adobe Commerce, 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.