Le prestazioni dei siti in WordPress sono un problema molto sentito e, altrettanto spesso, poco affrontato; il più delle volte si tende a sottovalutare questo genere di problematiche, e si tende a rinviare o nascondere il problema fin quando, ovviamente, le cose non degenerano. Il caso in questione riguarda la saturazione del numero di processi attivi contemporaneamente attivabili dall’hosting, che sono in genere 20 al massimo e che bloccano completamente il sito in caso di superamento di tale soglia (tipicamente con un errore 508).
Abbiamo già discusso della gestione della RAM in WordPress (vedi gli articoli: quanta RAM serve al nostro sito e come gestire la RAM in WP), e del relativo monitoraggio delle prestazioni della CPU, della memoria e del disco rigido del nostro hosting; in questo articolo parleremo di come ottimizzare il numero di processi attivi, considerando che (a meno che non abbiate un VPS) non c’è un modo pratico per visualizzarli all’interno del sito, ma bisogna ricorrere al monitoraggio delle prestazioni effettuato ad esempio da Plesk.
Un processo in termini generali corrisponde all’esecuzione di un compito prestabilito su una macchina qualsiasi; nel caso degli hosting web, tale limite può corrispondere a 20 o 25 processi in esecuzione contemporanea (per condivisi e reseller, di solito), e nessun limite (a parte quello fisico dell’hardware, ovviamente) per dedicati e VPS. Il fatto che un limite possa sembrare ampio o addirittura non prefissato non deve portarci a credere, insomma, che si debba sfruttare indebitamente la potenza della macchina, che è comunque limitata poichè deve fornire pari prestazioni a tutti (virtualizzazione).
Per vedere l’utilizzo dei processi del nostro sito, dobbiamo andare a verificare da cPanel o Plesk, sezione Statistiche e Uso risorse rispettivamente, e vedremo delle informazioni relative alle ultime 24 ore del sito. In caso di normalità , verranno semplicemente mostrate le statistiche di uso di CPU, memoria, input/output ed entry processes (che sono i processi attivi di cui parliamo).
Esempio (tratto da un mio sito)
Nei grafici, la linea rossa rappresenta il limite imposto (oltre il quale si ha un 508), mentre verde e blu sono rispettivamente uso medio e massimo della risorsa in questione.
Per chi non fosse a conoscenza, provo a riassumere brevemente il significato delle varie voci:
CPU: rappresenta il numero di istruzioni o comandi che il server deve eseguire che si ripercutono direttamente sulla potenza di calcolo del server, ovvero sul processore; di norma un sito web non sfrutta particolarmente questa risorsa, a meno che (come vedremo) non siano attivi particolari cron job, plugin o porzioni di codice inefficente.
RAM: la memoria viene tipicamente saturata in presenza di errori nel codice, oppure di situazioni non ben gestite all’interno dello stesso. Anche in quest’ambito le personalizzazioni possono giocare un ruolo determinante per saturare la memoria. Di norma, un sito WordPress occupa dai 40 ai 60 MB di memoria in condizioni normali, motivo per cui diventa spesso necessario reimpostare il memory_limit nel file php.ini (se l’hosting lo permette).
Input/Output: rappresenta i messaggi o le connessioni con l’esterno che il sito possiede, a differenza dei due casi precedenti in cui si sfruttano risorse locali. Esempi pratici sono, lato front-end, tipicamente le CDN che forniscono accesso alle librerie JS, eventuali ottimizzatori di immagini, CSS compressi hostati esternamente al sito e via dicendo. In questo caso se c’è un eccesso di uso della risorsa la cosa migliore è provare a localizzare le risorse internamente limitando il numero di connessioni con l’esterno.
Processi (entry process): rappresentano il numero di processi impiegati per far funzionare il sito. Il sistema operativo stabilisce come allocare e disallocare tali processi, e l’utente non può intervenire su tale politica salvo avendo accesso via SSH (e disponendo delle opportune, avanzatissime, competenze sull’argomento). Di norma, un sito WordPress non dovrebbe impegnare all’ottimo più di 5-10 processi alla volta.
Come ottimizzare il numero di processi, quindi? Nella mia esperienza la saturazione del numero di processi dipende da un certo numero degli stessi che rimane “appeso”, cioè il sistema non riesce a disallocarlo o chiuderlo correttamente: la mia ipotesi è stata che dipendesse da un errore nel codice. Per vedere il numero di errori esiste la modalità debug in WordPress, che può essere attivata come segue:
- si edita il file wp-config.php, e si aggiunge la porzione di codice riportata di seguito;
- si va a vedere nella cartella wp-content il file debug.log che conterrà tutti gli errori ed i warning generati dal sito.
Per ogni errore avrete un’indicazione precisa del tipo di bug, con tanto di path di riferimento: se si tratta di un errore nel core, cercate l’errore su Google e verificare che sia stato affrontato dagli sviluppatori dello stesso (quasi certamente sarà cosà¬, e vi daranno modo di risolvere da soli). Se si tratta di un errore generato da un plugin, sarebbe opportuno segnalarlo al creatore dello stesso e, in attesa di aggiornamenti, disattivarlo. Se sono errori nel theme o in vostre personalizzazioni, il suggerimento resta quello di correggerli oppure di cambiare theme. Non c’è un metodo più sistematico di questo per togliere di mezzo di errori, e per quello che ho visto c’è una buona probabilità che dipenda da qualche bug critico su qualche plugin; disattivandoli una volta e consultando il grafico di prestazioni aggiornato volta per volta, dovreste rendervi conto da soli di quale crei i problemi che vi affliggono.
Tenete conto, inoltre, che gli errori possono sia essere notificati direttamente nel markup HTML (sconsigliato per siti già pubblicati o molto visitati) sia loggati silenzionsamente nel file per una consultazione successiva. Questo si ottiene nel seguente modo (file da editare: wp-config.php, prima della riga /* That’s all, stop editing! Happy blogging. */):
//debug mode, mostra errori nel sito e li logga
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);
define('WP_DEBUG_LOG', true);
//debug mode, nasconde errori dal sito ma li logga
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);
//debug mode, mostra errori senza loggarli
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);
define('WP_DEBUG_LOG', false);
Un modo semplice e veloce, quindi, per togliere di mezzo ogni possibile errore: dopo aver fatto questa operazione su un sito critico in quanto ad errori 508 imprevisti, sono riuscito ad ottenere un rientro nella normalità come potete vedere dallo “stacco” del grafico nella parte finale. Si vede come i processi attivi siano rientrati nella media, dopo aver attraversato una fase in cui spesso saturavano a più di 20 alla volta.
👇 Da non perdere 👇
- 📈 Analizza Cellulari 📱
- 🔐 AI che dolor, Chat
- 🎯 Targetizza Database SQL 🗄
- 📊 Analizza Errori più comuni 📛
- 🚧 Costruisci Evergreen 📟
- 👩💻 Programma Gratis 🎉
- 💻 Configura Hosting a confronto 💑
- 🔒 Conosci Hosting reti e domini 💻
- 👩💻 Tapioca Informatica 🖥
- 💻 Iconizza Internet 💻
- 🔒 Gestisci Lavoro 🔧
- 💡 Mostra Marketing & SEO 🌪
- 🔑 Apprendi Meteo ⛅
- 🤯 Visiona Mondo Apple 🍎
- 🔍 Supervisiona Mondo Domini 🌐
- 🚀 Metti in cloud monitoraggio servizi online 📈
- 🔮 Anatomizza Nuove tecnologie 🖥
- 🔒 Antani PEC e firma digitale 📩
- 👀 Prematura Programmare 🖥
- 🎮 Lonfa Scrivere 🖋
- 🔒 Conosci Servizi di SMS 📶
- 👀 Guarda Sicurezza informatica e privacy digitale 🖥
- 🎮 Ricorda Siti web 🌎
- 🤖 Ottimizza Spiegoni 🎓
- 🧠 Neuralizza Svago 🎈
- 📡 Quantizza Usare Excel 🌀
- 🤖 Sovrascrivi Windows 😲
- 🎨 Personalizza Wireless 🚁
- 🔑 Decifra WordPress 🤵
- 💬 Il nostro canale Telegram: iscriviti
- 🔴 Stack: cos’è e come usarlo in informatica
- 🟠 Che significa LOL?
- 🟢 Plugin per i bottoni social su WordPress, quali usare?
