Come ottimizzare memcached e configurare al meglio

Memcached è uno dei modi più semplici e veloci per ridurre il carico su database e applicazioni web che ripetono spesso le stesse letture. Se configurato bene, può abbassare la latenza, ridurre il numero di query verso MySQL/MariaDB e alleggerire CPU e I/O. Se configurato male, invece, rischia di consumare memoria in modo inefficiente o di diventare un servizio esposto inutilmente in rete.

Questa guida va dritta al punto: come installarlo, come scegliere i parametri giusti, come controllare che stia davvero lavorando bene e come evitare gli errori più comuni. L’obiettivo non è “avere Memcached attivo”, ma ottenere un cache server stabile, prevedibile e utile sotto carico reale.

Quando Memcached ha senso

Memcached è adatto quando hai dati temporanei, ripetibili e facilmente rigenerabili. Funziona molto bene con siti dinamici, CMS, applicazioni PHP, dashboard, sessioni e oggetti applicativi che vengono richiesti spesso. È meno interessante se il tuo collo di bottiglia è altrove: query lente, codice inefficiente, assenza di cache lato applicazione o storage lento.

In pratica, Memcached aiuta soprattutto in questi casi:

• molte letture ripetute sul database;
• più utenti simultanei sullo stesso sito;
• WordPress, Drupal, Magento e applicazioni PHP con object cache;
• sessioni condivise tra più nodi, se progettato correttamente;
• riduzione del TTFB sulle pagine dinamiche.

Se invece il sito è quasi statico, o se il problema principale è un plugin pesante, un tema mal scritto o query non indicizzate, Memcached da solo non risolve. Va visto come acceleratore, non come cura universale.

Installazione base su Linux

Su Ubuntu e Debian l’installazione è semplice. Su AlmaLinux, Rocky Linux e CentOS il nome del pacchetto è simile, ma il servizio può cambiare leggermente in base alla versione.

Ubuntu / Debian

sudo apt update
sudo apt install memcached libmemcached-tools

Verifica subito che il servizio parta correttamente:

systemctl status memcached

Esito atteso: servizio active (running).

AlmaLinux / Rocky Linux / CentOS

sudo dnf install memcached libmemcached

Verifica il servizio:

systemctl status memcached

Se il servizio non parte, il primo controllo utile è vedere l’errore preciso:

journalctl -u memcached -n 50 --no-pager

Esito atteso: nessun errore di binding sulla porta, nessun problema di permessi, nessun conflitto con un altro processo.

Configurazione corretta del file principale

Il file più importante è di solito /etc/memcached.conf su Debian/Ubuntu oppure la configurazione del servizio su sistemi Red Hat based, spesso in /etc/sysconfig/memcached o in un file equivalente gestito dal pacchetto. Prima di modificare, fai sempre un backup.

sudo cp /etc/memcached.conf /etc/memcached.conf.bak

Se il file non esiste in quel percorso, controlla dove punta il servizio con:

systemctl cat memcached

Le opzioni più importanti sono queste:

• -m: memoria assegnata a Memcached in MB;
• -p: porta, di default 11211;
• -l: indirizzo di ascolto;
• -U: porta UDP, spesso meglio disattivarla;
• -c: numero massimo di connessioni simultanee;
• -t: numero di thread;
• -u: utente di esecuzione del servizio.

Una configurazione prudente per un server piccolo o medio può essere questa:

-m 256
-p 11211
-l 127.0.0.1
-U 0
-c 1024
-t 2

Qui il punto chiave è l’ascolto su 127.0.0.1: se Memcached serve solo la macchina locale, non deve restare esposto su tutte le interfacce. È una scelta più sicura e quasi sempre sufficiente per CMS e applicazioni sullo stesso server.

Come scegliere la memoria giusta

La variabile -m è quella che incide di più. Dare troppa poca memoria significa cache che si svuota di continuo; darne troppa può sottrarre RAM a database, web server e processi PHP-FPM.

Una regola pratica è partire da una quota contenuta e osservare il comportamento reale. Su server piccoli spesso bastano 64–256 MB; su server con più siti o applicazioni dinamiche si può salire a 512 MB, 1 GB o oltre, ma solo dopo aver verificato che la RAM totale sia abbondante e che il resto dello stack non soffra.

Il controllo da guardare è il tasso di hit rispetto ai miss. Se Memcached ha molti miss e saturazione rapida, serve più memoria o una cache meglio progettata. Se invece la memoria resta quasi vuota e l’uso è basso, hai allocato troppo.

Parametri che contano davvero

Non tutti i parametri hanno lo stesso peso. Nella pratica, quelli che meritano attenzione sono pochi e chiari.

-l indirizzo di ascolto

Per un server singolo, usa 127.0.0.1. Se devi accettare connessioni da altri host, fallo solo in rete privata o dietro firewall stretto. Esporre Memcached su Internet è una cattiva idea: in passato è stato spesso usato in attacchi di amplificazione e oggi non c’è motivo di lasciarlo aperto pubblicamente.

-U 0 disattiva UDP

Se non hai un motivo specifico per usare UDP, meglio spegnerlo. Riduce la superficie d’attacco e semplifica il comportamento del servizio.

-c connessioni simultanee

Se il sito riceve molte richieste, alza questo valore in modo ragionevole. Un valore troppo basso può creare code e rifiuti di connessione; uno troppo alto non risolve problemi strutturali ma aumenta il carico gestibile.

-t thread

Di solito 2 o 4 thread sono sufficienti su server piccoli e medi. Non ha senso esagerare su macchine con poca CPU. Il guadagno reale dipende dal profilo di traffico e dalla concorrenza.

-m memoria

È il parametro che devi monitorare nel tempo. Se il tuo sito cresce, la cache deve crescere con lui. Se il server ha altri ruoli importanti, Memcached non deve mai diventare il consumatore dominante di RAM.

Verifica della cache e metriche utili

Per capire se Memcached funziona davvero, non basta vedere il servizio attivo. Devi leggere le statistiche.

Con gli strumenti installati, puoi interrogare il server locale e controllare lo stato generale. Un test semplice è verificare che la porta risponda:

echo stats | nc 127.0.0.1 11211

Esito atteso: risposta con righe come STAT pid, STAT uptime, STAT curr_connections, STAT get_hits e STAT get_misses.

Le metriche più utili sono queste:

• get_hits: richieste servite dalla cache;
• get_misses: richieste non trovate in cache;
• curr_connections: connessioni attive;
• bytes: memoria usata;
• limit_maxbytes: memoria massima assegnata;
• evictions: oggetti rimossi per fare spazio;
• cmd_get: numero totale di get;
• cmd_set: numero totale di set.

Se vedi molte evictions, significa che la cache è troppo piccola o che i dati hanno un ciclo di vita troppo lungo rispetto allo spazio disponibile. Se gli hit sono bassi, Memcached non sta portando il beneficio atteso: o i dati non sono riutilizzati, o l’applicazione non lo usa bene.

Ottimizzazione per WordPress e applicazioni PHP

Su WordPress Memcached è utile soprattutto come object cache. Da solo non accelera tutto: deve essere supportato da un plugin compatibile e da un codice che sappia riusare gli oggetti salvati.

La strategia più sana è questa:

1. verificare che il plugin di cache sia compatibile con la versione PHP in uso;
2. attivare la cache oggetti solo dopo aver confermato che il backend risponde correttamente;
3. misurare TTFB, query ripetute e carico del database prima e dopo l’attivazione;
4. controllare che non aumentino errori PHP, timeout o consumo RAM.

Se usi un pannello come cPanel, Plesk o FastPanel, spesso il punto critico non è l’installazione del servizio, ma la coerenza tra estensione PHP, plugin e configurazione del sito. Se il plugin salva ma non legge, o se la cache viene svuotata troppo spesso, il vantaggio reale si riduce moltissimo.

Integrazione con PHP

In molti ambienti PHP serve anche l’estensione client. In base alla distribuzione e alla versione PHP, il pacchetto può cambiare, ma l’idea resta la stessa: il codice applicativo deve parlare con Memcached nel modo corretto.

Dopo l’installazione dell’estensione, controlla che sia caricata con:

php -m | grep -i memcached

Esito atteso: compare memcached. Se non compare, il modulo non è attivo nella CLI o nella versione PHP usata dal web server.

Ricorda che la CLI e PHP-FPM possono usare configurazioni diverse. Quindi un test in terminale non basta: bisogna verificare anche la versione PHP realmente servita dal sito.

Hardening minimo pratico

Memcached non deve mai essere trattato come un servizio “banale” solo perché è leggero. Il minimo indispensabile è questo:

• ascolto solo su localhost, se possibile;
• porta 11211 non esposta su Internet;
• UDP disattivato;
• firewall attivo e coerente con la rete reale;
• aggiornamenti regolari del pacchetto;
• monitoraggio di hit, miss, evictions e RAM.

Se il servizio deve parlare con altri host, limita l’accesso solo alle IP necessarie e solo su rete privata. Se puoi evitarlo, evita proprio l’esposizione esterna.

Controlli post-configurazione

Dopo ogni modifica, non fermarti al riavvio. Verifica sempre che il servizio sia stabile e che i valori siano quelli attesi.

sudo systemctl restart memcached
sudo systemctl status memcached

Esito atteso: servizio avviato senza errori. Poi controlla la porta:

ss -ltnp | grep 11211

Esito atteso: ascolto solo sull’indirizzo previsto. Se hai scelto 127.0.0.1, non devi vedere binding su 0.0.0.0 o sull’IP pubblico.

Infine, controlla le statistiche base:

echo stats | nc 127.0.0.1 11211 | head

Esito atteso: risposta immediata, senza timeout e senza errori di connessione.

Errori comuni e come leggerli

Un errore frequente è il mancato avvio per porta già occupata. In quel caso bisogna identificare il processo in conflitto prima di cambiare tutto a caso.

sudo ss -ltnp | grep 11211

Se la porta è già in uso da un altro servizio, l’errore non è Memcached “rotto”, ma una collisione di binding.

Altro caso comune: memoria insufficiente o configurazione troppo aggressiva. Se il servizio viene ucciso dal sistema, controlla i log di sistema e la pressione RAM totale. Su server piccoli, Memcached non deve competere con database, web server e processi PHP-FPM senza limiti chiari.

Se non vedi hit crescenti dopo l’attivazione, il problema può essere lato applicazione: plugin non compatibile, cache non realmente usata, oggetti con TTL troppo breve o chiavi scritte in modo incoerente.

Bilanciamento realistico delle risorse

La configurazione migliore non è la più alta, ma quella più equilibrata. Memcached rende bene quando riceve abbastanza RAM per tenere in cache gli oggetti utili, ma non così tanta da mettere in crisi il resto del server. Su una VPS con risorse limitate, è spesso meglio una cache moderata e ben monitorata che una configurazione esagerata.

La domanda giusta non è “quanta memoria posso dare?”, ma “quanta memoria posso togliere senza danneggiare il resto?”. Se il database ha bisogno di RAM per buffer e query cache equivalenti, e PHP-FPM deve evitare swap, Memcached va dimensionato con prudenza.

Mini checklist operativa

1. Installa Memcached e verifica che il servizio sia active (running).
2. Limita l’ascolto a 127.0.0.1 se non serve accesso remoto.
3. Disattiva UDP con -U 0 e scegli una RAM iniziale prudente.
4. Controlla get_hits, get_misses ed evictions dopo l’attivazione.
5. Valuta il miglioramento reale su TTFB, carico DB e consumo RAM.

Conclusione

Ottimizzare Memcached significa trovare il punto giusto tra sicurezza, memoria assegnata, concorrenza e uso reale da parte dell’applicazione. Se lo usi come cache locale, con ascolto ristretto, UDP spento e parametri dimensionati con criterio, ottieni un beneficio concreto senza complicare troppo lo stack.

La regola pratica è semplice: prima fai funzionare il servizio in modo pulito, poi misuri, poi aumenti solo ciò che serve. Memcached premia gli ambienti ordinati, non quelli improvvisati.