Ottimizzazione delle prestazioni di WordPress Parte 1: conosci le tue query sul database

Ci sono molte cattive abitudini che gli sviluppatori di WordPress dovrebbero evitare. Alcuni di questi includono l’uso dell’asterisco (*) per query SELECT  , query ridondanti e, soprattutto, non avere abbastanza familiarità con SQL.

Dopo anni di sviluppo su siti Web aziendali, gli sviluppatori spesso si pongono le seguenti domande:

• Perché non conoscevo questo metodo prima?
• Come potevo cavarmela prima?

La maggior parte degli sviluppatori che lavorano su WordPress riconosceranno che WordPress ha:

• Problemi di ottimizzazione costanti
• Problemi di scalabilità che possono causare interruzioni del sito
• Plugin di terze parti che creano carichi di database elevati

È pratica comune per uno sviluppatore di WordPress limitare la quantità di plugin installati e attivati sul proprio sito web. Il sovraccarico che un cattivo plug-in può infliggere a un sito Web è inimmaginabile. Quando ti affidi a plug-in di terze parti, le prestazioni del tuo sito Web sono alla mercé di quegli sviluppatori di terze parti. Se non hai una comprensione del codice nel plug-in, il plug-in potrebbe contenere una query inefficiente che potrebbe potenzialmente bloccare il tuo sito web. I plug-in inefficienti sono particolarmente difficili da rintracciare e potrebbero essere necessarie settimane per capire la causa del rallentamento del tuo sito.

L’argomento dell’ottimizzazione delle prestazioni può essere un argomento molto ampio da trattare. Invece di affrontare tutto in una volta, cercherò di affrontare una query di impaginazione che ha creato problemi di scalabilità per molti sviluppatori di WordPress. Questa è una query che vediamo spesso quando sviluppiamo su un sito WordPress.

Invece di dare immediatamente la soluzione, facciamo questo esercizio insieme.

Prenditi un momento e identifica 10 cose che puoi ottimizzare per questa seguente query:

SELECT SQL_CALC_FOUND_ROWS wp_posts.*, wp_postmeta.*
FROM wp_posts
INNER JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id)
INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id)
WHERE 1=1 AND ( wp_term_relationships.term_taxonomy_id IN (554) ) 
AND wp_posts.post_type = 'post' 
AND (wp_posts.post_status != 'draft' || wp_posts.post_status <> 'private' || wp_posts.post_status != 'trash')
AND CAST(wp_postmeta.meta_value AS CHAR) = 'episodes'
GROUP BY wp_posts.ID 
ORDER BY wp_posts.post_date DESC 
LIMIT 0, 10;
SELECT FOUND_ROWS();

Ecco un approccio migliore:

• • 1. wp_posts.* => wp_posts.post_title, wp_posts.post_content, wp_posts.post_name, wp_posts.post_date, wp_postmeta.meta_key, wp_postmeta.meta_valueElenca solo le colonne di cui hai bisogno. Più colonne hai elencato, più grande diventa il tuo oggetto per la memoria.
  • 2. WHERE 1=1 sarà sempre vero. Questa è una clausola ridondante. Ho sempre seguito la filosofia di mantenere le cose brevi e semplici! Segui il principio KISS. Se stai costruendo una clausola WHERE al volo e non sei sicuro di aver bisogno di espressioni aggiuntive nella  clausola WHERE , un 1=1 alla fine assicura che creerai una clausola WHERE valida in modo che l’istruzione SELECT  non esploda.
  • 3. wp_term_relationships.term_taxonomy_id IN (554)Per questa specifica affermazione, è inclusa solo 1 tassonomia. L’uso diretto di ‘=’  è il migliore per le prestazioni, seguito da IN.  Se sono presenti più di 2 tassonomie da chiamare, utilizzare  IN . OR è il più lento.
  • 4. (wp_posts.post_status != ‘draft’ || wp_posts.post_status <> ‘private’ || wp_posts.post_status != ‘trash’)!= AND <> sono entrambi terribili per le prestazioni, puoi ottenere gli stessi risultati usando wp_posts.post_status = ‘publish’ .
  • 5. CAST(wp_postmeta.meta_value AS CHAR) = ‘episodes’Questo è complicato perché meta_value è un tipo LONGTEXT e non è indicizzato dallo schema del database. L’utilizzo di questa coppia chiave/valore è leggermente più pesante in termini di risorse rispetto a meta_key o post_id nella tabella wp_postmeta .
  • 6. GROUP BY wp_posts.IDL’uso di GROUP BY può richiedere prestazioni elevate. Immagina l’algoritmo di ordinamento che deve essere eseguito per ottenere il set di dati di ritorno corretto.
  • 7. ORDER BY wp_posts.post_date DESC.ASC è la clausola ORDER BY predefinita . Il DESC sta sostanzialmente invertendo l’ordine cronologicamente, richiedendo l’esecuzione di un algoritmo aggiuntivo.
  • 8. LIMIT 0, 10L’uso del metodo offset può essere pessimo per le prestazioni. MySQL è in genere inadeguato per offset elevati . Immagina lo scenario  LIMIT 200000, 10 . Questo può essere problematico quando si impagina su una tabella intera memorizzando tutte le righe in memoria. Prendi in considerazione l’idea di incapsulare la query per consentire al sistema di leggere alcune righe alla volta. Una soluzione consiste nell’utilizzare un ID indicizzato “autoincrement” come alternativa.
  • 9. ‘OR’ è moderatamente più veloce in una frazione di secondo rispetto a ‘||’. Un altro vantaggio è la leggibilità. 
  • 10. SELECT FOUND_ROWS()Esecuzione di query inutili. Ciò avrebbe potuto essere ottenuto con una singola query efficiente.

Spero che questa prima parte della serie di prestazioni di WordPress ti sia piaciuta. Resta sintonizzato per la seconda parte.