Pagina 2 di 2
Ottimizzare senza misurare è tirare a indovinare. Prima di toccare una riga, la domanda giusta è sempre la stessa: dove sta davvero il collo di bottiglia? Quasi mai è dove il team pensa che sia, e quasi sempre è molto più economico da risolvere di un rewrite o di un server più grande. In questa categoria la performance è un metodo, non una collezione di trucchi.
Il primo tema è 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. Il denominatore comune è misurare il traffico reale, trovare il vero punto lento e intervenire lì, non ovunque.
Il secondo tema è 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 i problemi che non si vedono nel codice ma fermano l'azienda, e si risolvono con diagnosi, non con l'acquisto d'impulso di hardware.
Se un'applicazione o un server rallentano, vedi la consulenza IT e DevOps o scrivimi.
La prima regola dell'ottimizzazione è misurare. La seconda è misurare di nuovo dopo aver cambiato qualcosa.
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
Un database non ottimizzato rallenta operazioni e crescita, aumentando rischi e costi aziendali. Scopri perché investire nella Database Optimization è essenziale per garantire performance, sicurezza e competitività alla tua azienda. Continua a leggere
Laravel Octane 2.x oggi supporta FrankenPHP, Swoole e RoadRunner: tre driver con trade-off molto diversi. Per le PMI il problema non è "quanti RPS guadagno", ma se la codebase è pronta a vivere in memoria. Singleton, static state e persistent connections sono problemi documentati. Guida operativa: quando Octane ha senso, quando no, e come auditare la codebase prima del cutover. Continua a leggere
Un'applicazione Laravel lenta può costare caro alla tua PMI in termini di esperienza utente e conversioni. Laravel 12, abbinato alla potenza di Redis, offre strategie di caching avanzate per velocizzare il tuo sito. In questa guida pratica ti mostro come implementare object cache, query cache e altre tecniche per ridurre i tempi di risposta e il carico sui tuoi database. Continua a leggere
Tool gratuiti a supporto del tuo lavoro:
