Pagina 2 di 3
Ottimizzare senza misurare è tirare a indovinare. Prima di toccare una riga bisogna sapere dove sta davvero il collo di bottiglia: quasi mai è dove il team pensa che sia, e quasi sempre costa molto meno di un rewrite o di un server più grande. In questa categoria la performance è un metodo.
Gran parte degli articoli riguarda la performance applicativa, che quasi sempre significa accesso ai dati: query lente ed Eloquent N+1, caching a più livelli con Redis usato dove serve, code e worker per togliere il lavoro pesante dal percorso della richiesta, e le leve del runtime come OPcache, PHP-FPM e i fibers. In ogni caso si misura il traffico reale, si trova il punto lento e si interviene lì.
Altri trattano la performance di sistema, spesso ignorata finché non esplode: RAM e swap su VPS modesti, cron che si pestano i piedi a vicenda, spazio disco che si satura e ferma il servizio, sessioni PHP che affondano un portale nelle ore di punta. Sono problemi invisibili nel codice che però fermano l'azienda, e si risolvono con una diagnosi prima di comprare hardware d'impulso.
Se un'applicazione o un server rallentano, vedi la consulenza IT e DevOps o scrivimi.
Prima di ottimizzare si misura, e dopo ogni modifica si misura di nuovo.
Una piattaforma SaaS con 8 milioni di record nella tabella principale aveva query a 4 secondi nonostante tutti gli indici corretti. L'analisi ha mostrato che il problema non era l'indicizzazione ma il volume. Vi racconto l'approccio di sharding che abbiamo implementato con Laravel e come abbiamo gestito la migrazione live. Continua a leggere
Un'API Laravel che doveva fare 12 chiamate HTTP esterne per comporre una risposta impiegava 3,2 secondi in media. Con PHP Fibers e Octane ho portato lo stesso endpoint a 340ms senza cambiare l'architettura dell'applicazione. Vi spiego come funzionano i Fiber e come integrarli in modo sicuro con Laravel. Continua a leggere
Un VPS con 4 GB di RAM e zero swap: MySQL killato dall'OOM killer ogni notte durante l'import listini, con perdita di transazioni InnoDB. Come ho configurato uno swap file da 2 GB con swappiness a 10, perché ZRAM è spesso l'alternativa migliore su NVMe, e come proteggere i processi critici in modo permanente con systemd. Continua a leggere
Un portale Laravel con 200 utenti simultanei che diventava inutilizzabile nelle ore di punta: AJAX bloccati per 8-12 secondi, logout casuali, errori CSRF. La causa era il session locking su file. Migrazione a Redis con locking esplicito, TTL calibrato e garbage collection zero. Response time da 8s a 90ms. Continua a leggere
Un VPS Hetzner da 80GB al 100%: MySQL fermo, Laravel in errore 500, e dopo aver cancellato 30GB di log lo spazio non si liberava. La causa: file aperti da processi attivi. Diagnosi con ncdu, lsof e df -i, fix e configurazione logrotate per impedire che si ripeta. Continua a leggere
Un gestionale Laravel su Hetzner con MySQL che impiegava 3-4 secondi per ogni query di ricerca prodotti. La causa: InnoDB buffer pool a 128MB su un database da 6GB, reverse DNS lookup attivo e 47 query senza indice per ogni pagina catalogo. Diagnosi con slow query log, EXPLAIN e MySQLTuner, fix in due ore. Continua a leggere
Un VPS Hetzner con Laravel e 23 cron job tutti schedulati alle 02:00: load average a 47, MySQL in lock wait, import listini che si sovrappongono a sé stessi per tre ore. Ho ristrutturato l'intero scheduling con flock, nice/ionice, staggering e systemd timer. Il protocollo che applico a ogni VPS con più di 5 cron job. Continua a leggere
Una PMI lombarda con 8 sviluppatori e un monolite Laravel 10 lento aveva speso quattro mesi e 120.000 euro per migrare a microservizi. Risultato: tre servizi parzialmente funzionanti, zero in produzione, latenza raddoppiata e metà del team impegnato in infrastruttura Docker anziché in feature. La mia raccomandazione: fermare la migrazione, modularizzare il monolite con bounded context, e risolvere i veri problemi di performance. In due settimane il team era tornato produttivo. Continua a leggere
Un database MySQL da 12 GB su un VPS Contabo, un report mensile che impiegava 47 minuti, 38 indici su una tabella di cui 12 mai utilizzati, e una codebase Laravel 9 cresciuta per cinque anni senza che nessuno aprisse mai un EXPLAIN. Il caso reale di una PMI emiliana del marzo 2025: diagnosi con slow query log e EXPLAIN ANALYZE, invisible indexes per eliminare indici fantasma, tuning InnoDB, schema refactoring con migration sicure su tabelle da milioni di righe. Continua a leggere
Quando un'applicazione PHP rallenta sotto carico, il primo riflesso del cliente è "compriamo un server più grosso". È quasi sempre la mossa sbagliata e la più costosa. Il caso di un B2B veronese del gennaio 2025 in cui ho portato il checkout da 4,2 secondi a 280 millisecondi con otto ore di lavoro: fix del pattern N+1, un indice composito mancante, cache Redis usata male, tuning di OPcache e delle code asincrone. Continua a leggere
Tool gratuiti a supporto del tuo lavoro:
