Hosting database MySQL, 5 trucchi per aumentare performance e affidabilità

Il database è il cuore pulsante del nostro sito, quella componente dell’infrastruttura che ci permette di offrire i nostri contenuti agli internauti. Migliorare quindi il proprio database per renderlo performante e affidabile al massimo è una condizione indispensabile per avere successo.


Ottimizzare il database del proprio sito Internet è un’operazione estremamente complessa e condizionata da tanti variabili. Se gestiamo applicazioni o siti che devono supportare numerosi accessi contemporanei o gestire una base di dati che nel tempo è diventata complessa, è possibile che si verifichino cali di prestazioni.
Vediamo quindi nel dettaglio 5 trucchi per migliorare in modo sostanziale le prestazioni del nostro database MySQL basato su motore InnoDB (cuore dai maggiori CMS come WordPress, oltre che da Prestashop e Magento).

 

1. Quanta RAM?

Uno dei parametri più importanti da modificare in prima battuta è il parametro innodb_buffer_pool_size, che indica quanta RAM può essere utilizzata per memorizzare i dati, evitando così continui accessi al disco. Ma come possiamo quantificare il valore da attribuire al buffer?

Poniamo la condizione di avere un server su cui risiedono sia il webserver che MySQL, con 8GB di RAM; in questo caso dedicheremo a innodb_buffer_pool_size 4GB, cioè circa la metà delle risorse computazionali. Nel caso invece di un server dedicato interamente a DB con una RAM a disposizione di 12GB, sono circa 10GB quelli da dedicare ad inno_db.

 

2. Il numero massimo delle connessioni

Un altro potenziale pericolo è rappresentato dalla possibilità di crash del server, a causa delle eccessive richieste di connessione. Non sempre infatti il numero di connessioni disponibili equivale al numero di connessioni effettive: non settando il numero massimo di richieste in entrata, i server MySQL consumano più RAM per funzionare rispetto a quanta effettivamente necessaria, rallentando così in modo deciso il vostro sito rendendolo nei peggiori dei casi irraggiungibile.

 

3. Il parametro resolver

Per i client che utilizzano MySQL da remoto, viene mantenuto un file in cache che memorizza indirizzo IP, nome dell’host e altre informazioni. Per far ciò il server tenta una risoluzione DNS IP > host name. Se i DNS interni alla LAN non forniscono un DNS lookup reverse allora è possibile che si verifichino dei rallentamenti nelle connessioni, questo perché ogni volta il resolver tenterà di inserire il nome dell’host nella cache (registrando sempre un timeout di connessione). Per disabilitare il DNS host name lookup è sufficiente far partire MySQL con l’opzione attiva -skip-name-resolve.

 

4. Il peso delle tabelle

Purtroppo in generale MySQL non ha tra le sue features l’ottimizzazione delle tabelle, che deve essere eseguita manualmente ogni volta ne venga percepito il bisogno o durante la fase di monitoraggio. Cosa intendiamo con ottimizzazione delle tabelle? La riduzione dei byte in eccesso che si genera con la modifica o la cancellazione di una qualsiasi riga di record.

Se ad esempio, un campo che contiene del testo occupa 100 byte e poi il campo viene modificato, occupando quindi “solo” 90 byte, il sistema continuerà a registrare per quella riga un consumo di 100 byte, ovvero 10 in eccesso.
Lo stesso discorso avviene analogamente quando si procede a cancellare un record dalla tabella: se una tabella occupa 1GB e al suo interno viene cancellato un record che occupa 150 byte, ci troveremo con una tabella di 850 byte. Tramite il comando Optimize Table, il database viene compresso recuperando lo spazio vuoto, rendendo più efficiente l’operazione di accesso ai dati.  

 

5. I file di cache

Quando un’applicazione ha molti dati in lettura questi possono accumularsi nella memoria del server, rallentandolo. Generalmente i valori compresi tra 256 e 2048MB sono i migliori: a seconda della potenza del proprio server ed impostando i giusti parametri, è possibile ottenere un miglioramento in termini di caricamento delle pagine di 2,5 secondi al primo accesso e 1,3 secondi sulle pagine chiamate una seconda volta, contro i 3,4 secondi di media di caricamento prima dell’ottimizzazione della query.