Lo strumento APM di Kinsta

Lo strumento APM di Kinsta aiuta a identificare i colli di bottiglia delle prestazioni PHP sul vostro sito WordPress senza dover sottoscrivere servizi di monitoraggio di terze parti come New Relic.

Disponibile senza costi aggiuntivi su tutti i piani, lo strumento APM può essere molto utile per la risoluzione dei problemi di un sito web. Lo strumento APM è progettato per acquisire informazioni con data e ora sui processi PHP del vostro sito WordPress, sulle query al database MySQL, sulle chiamate HTTP esterne e altro ancora.

Grazie ai dati dell’APM, potete indagare su specifici carichi di pagina lenti per identificare la causa principale del problema. Per maggiori dettagli sulla risoluzione di problemi di prestazioni su specifici tipi di siti utilizzando lo strumento APM, consultate queste guide:

• Come risolvere i problemi di prestazioni di WooCommerce utilizzando l’APM di Kinsta
• Come risolvere la velocità del vostro sito web di membership con lo strumento APM di Kinsta

Tenete presente che lo strumento APM di Kinsta è stato progettato specificamente per aiutarvi a monitorare i siti WordPress, quindi usarlo per monitorare un sito che funziona con un altro CMS o framework potrebbe portare a risultati imprecisi. Pertanto, vi consigliamo di usarlo solo per i siti WordPress.

Terminologia dello strumento APM

Prima di scoprire come utilizzare lo strumento APM, definiamo alcuni termini importanti che verranno utilizzati in seguito.

APM

APM, acronimo di “Application Performance Monitoring”, è uno strumento che permette di conoscere le statistiche e le tendenze delle prestazioni di un’applicazione. Lo strumento APM di Kinsta fornisce dati utili sulle prestazioni del vostro sito WordPress.

Request

Nel contesto dello strumento APM, una request, o richiesta, si riferisce a una visita al sito WordPress che richiede l’esecuzione di PHP per il rendering. L’URL di una richiesta può includere vari parametri di stringa di query e attiva una transazione corrispondente.

Ad esempio, una richiesta a yourdomain.com/wp-cron.php?arg=1&arg2=2 attiverà una transazione /wp-cron.php.

Transaction

Una transaction, o transazione, si riferisce all’attività di backend che avviene per servire una richiesta al sito WordPress. Ad esempio, la transazione per una richiesta a /wp-login.php contiene i singoli processi PHP che generano la pagina di login del vostro sito WordPress.

Span

Uno span, o intervallo, si riferisce a un singolo processo di una transazione. Una singola transazione può essere composta da centinaia di span disposti gerarchicamente.

Ad esempio, una transazione che genera una pagina di account per un cliente di WooCommerce può essere composta da un intervallo che si suddivide in più intervalli di query al database.

Transaction sample

Un transaction sample, o campione di transazione, si riferisce a un’istanza selezionata di molte richieste a uno specifico endpoint di transazione (ad esempio /single.php, /wp-cron.php, ecc.). Nello strumento APM avrete a disposizione tre campioni tra cui scegliere.

Ad esempio, lo strumento APM potrebbe registrare decine di transazioni /wp-cron.php. In questo caso, lo strumento APM sceglierà la transazione più lenta e la chiamerà campione di transazione.

Transaction trace

Una transaction trace, o traccia di transazione, è una linea temporale completa di tutti i processi che si sono verificati in un campione di transazione. Nel nostro strumento APM, una traccia di transazione è rappresentata da un elenco di intervalli con le relative informazioni di durata e timestamp.

Stack trace

Una stack trace, o traccia di stack, è una ripartizione dettagliata del processo per un singolo intervallo. Le stack trace sono utili per un debug approfondito. Contengono informazioni molto dettagliate sul codice PHP che è stato eseguito, fino a un file PHP specifico e a una riga di codice.

Abilitare lo strumento APM di Kinsta

Per impostazione predefinita, lo strumento APM è disabilitato. Poiché lo strumento APM richiede ulteriori risorse del server, vi consigliamo di abilitarlo solo quando state attivamente risolvendo un problema di prestazioni sul vostro sito WordPress.

Per abilitare lo strumento APM, accedete a MyKinsta, scegliete il sito che volete monitorare, andate alla scheda APM del vostro sito e cliccate sul pulsante Abilita APM.

Successivamente, selezionate la durata del monitoraggio per l’APM. Potete scegliere tra 2 ore, 4 ore, 12 ore e 24 ore. Poiché l’APM può ridurre le prestazioni del vostro sito, non consigliamo di lasciarlo attivo per un periodo di tempo prolungato. Una volta selezionata la durata del monitoraggio, cliccate su Attiva il monitoraggio per avviare l’APM.

Lasciate allo strumento 5-10 minuti per iniziare a raccogliere i dati e poi potrete visualizzarli nella scheda APM.

Al termine della durata del monitoraggio, APM verrà disattivato automaticamente. Se volete disattivare il monitoraggio in anticipo, cliccate sul menu a tendina e selezionate Disattiva.

Selezionare un intervallo di tempo per il monitoraggio dei dati

Per impostazione predefinita, lo strumento APM mostra i dati di monitoraggio degli ultimi 60 minuti. Tuttavia, l’intervallo di tempo dei dati è personalizzabile e potete scegliere tra le opzioni seguenti.

• 30 minuti
• 60 minuti
• 2 ore
• 4 ore
• 12 ore
• 24 ore

Per modificare questa impostazione, fate clic sul pulsante della cornice temporale in alto a destra nella pagina APM e selezionate un’opzione nella finestra modale/pop-up che appare. Cliccate sul pulsante Applica l’intervallo di tempo per impostare la nuova cornice temporale.

Aggiornare i dati di monitoraggio

Lo strumento APM di Kinsta visualizza i dati di monitoraggio delle prestazioni in base all’intervallo di tempo impostato (es. 30 minuti fa, 60 minuti fa, ecc.). Per evitare confusione, lo strumento APM non aggiorna automaticamente i dati. Per aggiornare lo strumento APM e visualizzare i dati più recenti dell’intervallo di tempo selezionato, cliccate sull’icona di aggiornamento accanto al pulsante dell’intervallo di tempo.

Leggere i risultati dell’APM

Poiché la registrazione dei dati inizia solo dopo che lo strumento APM è stato abilitato, dovrete dargli un po’ di tempo per raccogliere i dati sulle prestazioni del vostro sito. Vi consigliamo di attendere 5-10 minuti prima di esaminare i dati di monitoraggio.

Dopodiché, le informazioni principali si trovano nelle schede Transactions, WordPress, Database ed External, che analizzeremo in dettaglio qui di seguito.

Ci sono alcune colonne comuni che vedrete in ogni scheda:

1. Total Duration (%): la percentuale di tempo, rispetto alla Durata totale, consumata da tutte le richieste a un endpoint di transazione nell’arco di tempo selezionato. La percentuale di durata è calcolata con i valori della Durata totale (la somma della durata di tutte le richieste a un particolare endpoint), quindi non rappresenta la durata di un campione di transazione individuale.
2. Total Duration: la quantità totale di tempo consumata da un endpoint di transazione nell’arco di tempo selezionato. Si noti che la durata si riferisce alla somma della durata di tutte le richieste a un particolare endpoint e non rappresenta la durata di una singola transazione campione.
3. Max Duration: la durata del campione di transazione più lento dell’intervallo di tempo selezionato.
4. Avg. Duration: la media di tutte le durate dei campioni delle transazioni nell’intervallo di tempo selezionato.
5. Rate Per Min: il numero di volte in cui una transazione è stata eseguita in media al minuto nell’intervallo di tempo selezionato.

Navigando tra i dati, vedrete anche questi dettagli comuni:

Campioni di transazioni

Facendo clic su una transazione, vi verrà presentata una finestra contenente fino a tre campioni di transazioni dell’intervallo di tempo selezionato.

1. Slowest sample: il campione di transazione più lento.
2. 95th percentile: una transazione nel 95° percentile (il 95% delle transazioni è più veloce di questo campione).
3. 50th percentile: una transazione nel 50° percentile (il 50% delle transazioni è più veloce di questo campione di transazioni), detta anche mediana. Possiamo considerarla la durata tipica, dato che ci sono esattamente la stessa quantità di campioni più lenti e più veloci rispetto a questo.

Potete vedere uno, due o tre campioni. Ad esempio, la stessa transazione può essere il campione più lento e il 95° percentile.

La finestra modale/pop-up dei campioni di transazione mostra anche informazioni utili su ogni campione di transazione, tra cui il timestamp, l’endpoint della transazione, l’URL della richiesta e la durata.

Campione di transazione individuale

Se fate clic su un campione di transazione nella finestra, verrete indirizzati a una pagina dedicata al campione selezionato. La pagina del campione di transazione include il timestamp del campione, l’endpoint della transazione, l’URL, la durata, il codice di stato HTTP e la cronologia completa della traccia della transazione.

1. Timestamp: la data e l’ora del campione della transazione.
2. Transaction: l’endpoint PHP del campione della transazione (ad esempio /wp-cron.php, /single.php, ecc.).
3. URL: l’URL specifico del campione della transazione.
4. Duration: la durata del campione della transazione in millisecondi.
5. Result: il codice di stato HTTP della transazione. Se vedete un risultato “HTTP 200“, significa che la transazione è stata lenta ma alla fine è andata a buon fine. Se invece vedete un risultato “HTTP 503“, potrebbe significare che la transazione si è interrotta.

Ogni campione di transazione ha un proprio permalink o un URL unico. In questo modo è facile fare riferimento e condividere un campione di transazione specifico con i vostri colleghi, con uno sviluppatore o con il team di supporto di Kinsta. Nota: il vostro collega o sviluppatore dovrà avere accesso al sito in MyKinsta per poter visualizzare il campione di transazione.

Transaction trace timeline

Oltre alle informazioni di base sulle transazioni, lo strumento APM offre anche una timeline più dettagliata delle transazioni. All’interno della timeline della traccia delle transazioni, potete vedere una presentazione graduale degli intervalli – processi PHP, query del database MySQL e chiamate esterne per un particolare esempio di transazione.

Potete ordinare gli intervalli per Durata (tempo) o Durata (%) in ordine crescente o decrescente cliccando sul nome della colonna. Questo è utile per identificare rapidamente le transazioni più lunghe.

Ogni intervallo ha anche la sua durata associata e il relativo timestamp, in modo da poter identificare rapidamente la parte più lunga e problematica della richiesta.

Relativo alla durata totale del campione di transazioni:

• Gli intervalli con una durata superiore al 5% sono indicati in arancione
• Gli intervalli con una durata superiore al 25% sono mostrati in rosso

Queste evidenziazioni si riferiscono sempre alla durata relativa dell’intervallo nel contesto del campione. Quindi, se vedete qualcosa di rosso, tenete conto che è sempre riferito a quel determinato campione (e il vostro sito o la vostra applicazione web potrebbero non essere lenti nel loro complesso).

Si noti che per le query MySQL e Redis, non includiamo intervalli più brevi di 0,001 ms. Per gli intervalli non legati alla base dati, la soglia è di 1 ms. Escludiamo di proposito gli intervalli brevi perché la registrazione di un numero elevato di elementi veloci può avere un impatto sulle prestazioni del sito e non fornisce dati molto utili.

Questa cronologia dettagliata è molto utile per la risoluzione dei problemi di prestazioni perché aiuta a individuare esattamente il collo di bottiglia.

Ad esempio, potreste notare che la lentezza quando viene richiesto /wp-admin/admin-ajax.php è causata da lunghe richieste API alle API dei social network. Armati di queste conoscenze, potete continuare a testare il vostro sito con il plugin social disattivato per vedere se fa la differenza.

Allo stesso modo, se vedete una transazione lenta su /wp-cron.php che contiene richieste HTTP ripetitive iniziate da un plugin di precaricamento della cache, potete agire rapidamente su questa informazione e disabilitare la funzionalità di precaricamento della cache.

Dettagli dell’intervallo

Se fate clic su un intervallo nella timeline della traccia delle transazioni, potrete vedere una panoramica dettagliata con una traccia completa dello stack e le informazioni associate.

Ad esempio, se fate clic su un intervallo di query MySQL, vedrete la query del database che è stata eseguita insieme allo stack trace. Esaminando i dettagli dell’intervallo, potete ottenere una visione più approfondita delle transazioni PHP sul vostro sito WordPress.

Per esempi più specifici su come leggere e utilizzare i dati dello strumento APM, consultate la nostra guida sull’uso dello strumento APM di Kinsta per diagnosticare i problemi di prestazioni.

Monitoraggio dei risultati

In ognuna delle schede della pagina APM potete visualizzare i dati specifici delle transazioni, di WordPress, del database e delle richieste esterne.

Transactions

In questa scheda troverete i dati sul tempo complessivo delle transazioni e sulle transazioni più lente.

Overall Transaction Time

Il grafico a barre del tempo complessivo delle transazioni fornisce una rappresentazione visiva dei dati relativi al tempo delle transazioni nel periodo di tempo selezionato. Ogni barra è composta da una suddivisione multicolore dei tempi di transazione di PHP, MySQL, Redis ed Esterno. Il grafico del tempo di transazione complessivo mostra anche il tempo medio di transazione del periodo selezionato nell’angolo in alto a destra.

Slowest Transactions

Le dieci transazioni PHP più lente appaiono nella sezione Slowest Transactions (Transazioni più lente), sotto il grafico a barre del tempo complessivo delle transazioni. Oltre alle colonne comuni, la prima colonna di questi dati è la colonna Transaction, che mostra l’endpoint della transazione delle richieste lente che hanno consumato più tempo PHP (ad esempio /wp-cron.php, /wp-json, ecc.).

Potete cliccare su ogni endpoint di transazione per visualizzare i campioni di transazione e navigare più a fondo in ogni singolo campione di transazione, nella timeline della traccia, nei dettagli dell’intervallo e nello stack trace.

WordPress

Nella scheda WordPress troverete dati specifici per i plugin e gli hook di WordPress.

I plugin WordPress più lenti

I plugin più lenti registrati sono elencati in alto con lo slug (nome della cartella/directory) del plugin nella prima colonna, poi le altre colonne di dati comuni. Potete cliccare su ogni slug del plugin per visualizzare i campioni delle transazioni e navigare più a fondo in ogni singolo campione di transazione, nella timeline della traccia, nei dettagli dell’intervallo e nello stack trace.

Hook WordPress più lenti

Sotto l’elenco Slowest WordPress plugins, vedrete l’elenco degli hook WordPress più lenti. Gli hook di WordPress sono funzioni presenti nei temi o nei plugin che permettono di modificare WordPress in punti specifici dell’elaborazione del codice.

Un hook può essere un’azione o un filtro e gli hook di questo elenco sono preceduti dal loro tipo (action o filter), seguito dal nome della funzione. Facendo clic su un hook vengono visualizzati gli esempi di transazione, dove è possibile approfondire ogni singolo esempio di transazione, la trace timeline, i dettagli dell’intervallo e lo stack trace.

Database

Questa scheda mostra i dati relativi alle query più lente del database e alle transazioni più lente della cache Redis (se Redis è abilitato).

Query del database più lente

Le 10 query di database più lente sono mostrate nella sezione Slowest database queries. Facendo clic su una query vengono mostrati i campioni delle transazioni, dove è possibile approfondire ogni singolo campione di transazione, la trace timeline, i dettagli dell’intervallo e lo stack trace.

La cache Redis più lenta

Per i siti con l’add-on Redis, i dettagli relativi alla cache di Redis si trovano in questa sezione. Se il vostro sito non ha installato il componente aggiuntivo Redis, non verrà mostrato alcun dato. Facendo clic su un elemento della cache, vengono visualizzati i campioni delle transazioni, dove è possibile approfondire ogni singolo campione di transazione, la trace timeline, i dettagli dell’intervallo e lo stack trace.

External

I dati relativi alle richieste esterne effettuate dal vostro sito si trovano nella scheda External. Le richieste esterne sono richieste HTTP effettuate dal vostro sito a un altro sito o server. Queste chiamate vengono solitamente effettuate da plugin o temi per recuperare o inviare dati o per comunicare con un’API.

Ogni URL nella prima colonna dell’elenco è seguito dal metodo HTTP utilizzato per la richiesta (GET, POST, PUT, ecc.). Cliccando sull’URL di una richiesta vengono mostrati i campioni di transazione, dove è possibile approfondire ogni singolo campione di transazione, la timeline delle tracce, i dettagli dell’intervallo e lo stack trace.

Diagnosticare i problemi di prestazioni

Lo strumento APM di Kinsta è un potente strumento per la risoluzione dei problemi del vostro sito web. Questo articolo vi illustrerà alcuni scenari diversi per la risoluzione di problemi di prestazioni su un sito, utilizzando lo strumento APM per indagare e analizzare i problemi.

Come iniziare

Prima di immergervi nell’uso dello strumento APM per risolvere un problema, ci sono alcuni passi da compiere, indipendentemente dal problema:

1. Assicuratevi di poter ricreare il problema se non si sta verificando. Cercate di capire quando si verifica il problema o se alcune azioni specifiche sembrano scatenarlo (ad esempio la modifica di una pagina, l’aggiunta di un prodotto al carrello di un ecommerce, il caricamento di immagini, ecc.)
2. Attivate lo strumento APM in MyKinsta e concedetegli qualche minuto per iniziare a raccogliere i dati. Lo strumento APM può registrare e analizzare i dati solo quando è abilitato.
3. Una volta che lo strumento APM inizia a raccogliere i dati, duplicate il problema per registrare le informazioni necessarie.
4. Se Redis è abilitato sul vostro sito, assicuratevi di utilizzare il plugin WP Redis o Redis Object Cache (ma non entrambi). Potremmo non essere in grado di raccogliere e mostrare i dati di Redis da altri plugin nello strumento APM di Kinsta.

Analizzare le pagine o le azioni che si caricano lentamente

In questo esempio, le pagine si caricano rapidamente, ma tutto rallenta quando si aggiunge un prodotto al carrello, sia esso semplice o variabile.

Dopo aver aggiunto alcuni prodotti al carrello, diamo un’occhiata ai risultati nell’APM (Siti WordPress > nome sito > APM) e vediamo che la transazione /single-product è in cima alla lista delle transazioni più lente, con una durata massima di oltre 5 secondi e una durata media di oltre 2 secondi.

Cliccando su questa transazione si apre la finestra modale/pop-up Transaction samples in cui possiamo selezionare la transazione più lenta (la prima dell’elenco) per vedere maggiori dettagli.

Questo ci porta alla timeline della traccia delle transazioni, dove possiamo ordinare le transazioni per Durata (tempo) per vedere quali sono i processi più lenti in questo campione di transazioni. Qui possiamo vedere che l’intervallo update_card_payment è il processo più lento nella timeline, con 5.002,21 ms su una transazione di 5.535,61 ms.

Facendo clic su questo intervallo si apre la finestra/pop-up dei dettagli dell’intervallo e viene visualizzata la traccia dello stack dell’intervallo.

Possiamo vedere che l’hook di WordPress action:woocommerce_add_to_cart è associato a questo span nei dettagli dello span.

Ci sono un paio di modi per individuare il plugin o il tema a cui è associato.

Se avete dimestichezza con la riga di comando, potete usare il comando grep per cercare la funzione update_card_payment e vedere quali file di plugin o temi contengono tale funzione.

In alternativa, potete consultare la scheda WordPress alla voce Monitoring Results e cercare un plugin con una durata totale e una durata massima simili. Molto probabilmente sarà in cima all’elenco.

Potete confermare la corrispondenza selezionando il plugin nell’elenco dei plugin WordPress più lenti. Se il plugin non è elencato nella colonna dei plugin WordPress nella finestra modale/pop-up Transaction samples, selezionate il campione di transazione più lento per visualizzare la cronologia della traccia delle transazioni.

Ordinate la cronologia per Durata e cercate il nome della stessa funzione (ad esempio update_card_payment) in cima all’elenco.

Indagine sulla lentezza complessiva

La lentezza generale di un sito è spesso dovuta a un plugin ed è uno dei primi punti da controllare. Se è un plugin a causare la lentezza del vostro sito, di solito è possibile identificarlo visualizzando la scheda WordPress (Siti WordPress > nome del sito > APM > WordPress). Nella schermata qui sotto, noterete che la percentuale di durata totale del plugin evidenziato è superiore al 98% e che la durata massima e media sono piuttosto elevate.

Ciò indica che questo plugin è la fonte più probabile della lentezza complessiva del sito. Per confermarlo, possiamo disattivare il plugin, osservare le prestazioni del sito e controllare nuovamente i risultati nello strumento APM dopo aver raccolto un numero sufficiente di dati. Se siete sicuri che il plugin è configurato correttamente ma continua a causare rallentamenti sul vostro sito, vi consigliamo di contattare lo sviluppatore del plugin per risolvere il problema.

Individuare i problemi intermittenti di terze parti

Le richieste esterne sono richieste HTTP fatte dal sito a un altro server (di terze parti). I plugin o i temi di solito fanno queste richieste per caricare script o fogli di stile o per comunicare con un’API.

Quando si risolve un possibile problema esterno, è importante notare che lo strumento APM registra le transazioni esterne lente sul lato server. Molte richieste esterne possono essere effettuate da un sito sul lato client, che non verrebbero registrate dallo strumento APM. Per analizzare le richieste esterne sul lato client, dovrete utilizzare uno strumento come GTmetrix o gli strumenti di sviluppo del browser.

Per visualizzare le richieste esterne lente, andate alla scheda External sotto Monitoring Results per visualizzare le richieste esterne più lente. In questo esempio, abbiamo notato una certa lentezza nel caricamento delle immagini nella libreria multimediale, con alcuni caricamenti che richiedono 5 minuti o più per essere completati.

Iniziamo a vedere come appaiono le richieste esterne quando non stiamo facendo altro che accedere alla dashboard di WordPress. Prima di caricare le immagini nella libreria multimediale, le richieste di POST a wp-cron sono le più lente, con 273,78 ms di durata massima e 1.957,81 ms di durata totale.

Quando carichiamo diverse immagini di dimensioni comprese tra 3MB e 17MB, ci vogliono diversi minuti prima che finiscano di essere caricate. Osservando nuovamente le richieste esterne, vediamo che le richieste di POST a smushpro.wpmudev.com sono le richieste esterne più lente, con una durata massima di 1.703,14 ms e una durata totale di 82.710,85 ms.

Cliccando su questa transazione si apre la finestra modale/pop-up Transaction samples in cui possiamo selezionare la transazione più lenta (la prima dell’elenco) per vedere maggiori dettagli.

In questo modo si accede al Transaction trace timeline, dove è possibile ordinare le transazioni per Durata (tempo) per vedere quali sono gli intervalli più lenti. Qui possiamo vedere che diverse richieste di POST a smushpro.wpmudev.com sono le più lente in questo campione, con il totale di queste richieste di POST che occupano 6.712,64 ms di una transazione di 7.168,58 ms.

Possiamo anche osservare che la durata di ogni richiesta varia in modo significativo, con la richiesta più breve che richiede solo 138,2 ms e quella più lunga che richiede 1.703,14 ms. Quindi, mentre il plugin Smush ottimizza le nostre immagini, ognuna di esse genera una richiesta esterna che si somma e può rallentare il sito.

In questo caso, ottimizzare le immagini prima del caricamento invece di affidarsi a un plugin per l’ottimizzazione delle immagini ridurrebbe notevolmente le richieste esterne. Questo è uno di quei casi in cui dobbiamo decidere cosa è più importante, se la convenienza o le prestazioni del sito. Possiamo mantenere il plugin se siamo d’accordo con la necessaria lentezza causata dalle richieste esterne. Se invece preferiamo o abbiamo bisogno di migliorare le prestazioni del sito, la soluzione migliore è rimuovere il plugin e ottimizzare le immagini prima di caricarle.

Domande frequenti sull’APM

Abbiamo raccolto alcune domande frequenti sull’APM e abbiamo fornito le relative risposte qui di seguito.

Come si attiva l’APM di Kinsta?

L’APM di Kinsta è disponibile senza costi aggiuntivi per tutti i piani. Per attivarlo, è necessario:

1. Accedere a MyKinsta.
2. Selezionare il sito web che si desidera analizzare.
3. Cliccare sulla scheda Monitoraggio.
4. Cliccare sul pulsante Abilita APM per avviare lo strumento APM.

L’APM rallenterà il sito WordPress?

Come per altri strumenti APM, l’agente APM di Kinsta potrebbe aggiungere ulteriore carico alle risorse CPU e RAM del vostro server e potrebbe potenzialmente rallentare il vostro sito WordPress per un periodo di tempo limitato.

Vi consigliamo vivamente di attivare l’APM solo quando state attivamente diagnosticando un problema di prestazioni sul vostro sito.

Kinsta supporta ancora il monitoraggio personale di New Relic per i clienti con licenze personali di New Relic?

Sì, i siti Kinsta supportano ancora il monitoraggio New Relic per i clienti con licenze personali.

È possibile utilizzare contemporaneamente l’APM di Kinsta e New Relic?

Non consigliamo di utilizzare contemporaneamente APM di Kinsta e New Relic per il monitoraggio. Tuttavia, è possibile passare dall’APM a New Relic a patto che i due strumenti non siano attivi contemporaneamente.

L’APM è compatibile con altre piattaforme e framework CMS?

Al momento, l’APM è pienamente compatibile solo con WordPress.

L’APM funziona con Bedrock (o altri siti che utilizzano Composer)?

Sì, ma se WP-CLI è una dipendenza nel file composer.json del vostro sito, dovrete aggiungere una configurazione in modo che l’autoloader di Kinsta possa lavorare insieme all’autoloader di WP-CLI:

"prepend-autoloader": false

Ecco un esempio di configurazione di un sito Bedrock dopo aver aggiunto la configurazione prepend:

"config": {
"optimize-autoloader": true,
"preferred-install": "dist",
"prepend-autoloader": false
},

Cosa succede se si verifica un comportamento inaspettato sul sito dopo aver attivato l’APM?

Abbiamo già effettuato test approfonditi con diverse versioni di WordPress e un lungo elenco di plugin. Tuttavia, ci possono essere ancora delle incognite da risolvere, come la versione di un plugin o uno sviluppo personalizzato incompatibile con la nostra soluzione di monitoraggio.

Per questo motivo, quando attivate la funzione, controllate sempre che il vostro sito funzioni correttamente. Se notate un comportamento indesiderato, disattivate la funzione e comunicatecelo così da lasciarci indagare e risolvere il problema.

Per quanto tempo sono disponibili i dati dello strumento APM?

I dati APM vengono conservati per 14 giorni. Per visualizzare i dati più vecchi di 24 ore, fate clic sul pulsante della cornice temporale in alto a destra nella pagina APM, andate alla scheda Assoluto nella finestra modale/pop-up Seleziona intervallo di tempo, selezionate una cornice temporale di 24 ore negli ultimi 14 giorni e fate clic sul pulsante Applica intervallo di tempo.

Riepilogo

Lo strumento APM di Kinsta fornisce un contesto ai problemi di performance del vostro sito WordPress. Invece di generici errori HTTP 502 o timeout, lo strumento APM fornisce dettagli sulle richieste lente.

Con lo strumento APM di Kinsta, potrete eseguire il debug dei problemi di prestazioni senza installare un plugin come Query Monitor o attivare un servizio di terze parti come New Relic.

Se state lavorando con uno sviluppatore per risolvere i problemi del vostro sito WordPress, lo strumento APM di Kinsta può anche aiutarvi a risparmiare tempo e denaro fornendovi un buon punto di partenza.