Benchmarking Qwen3.6-35B-A3B on a 16GB RTX 5060 Ti: A Full Engineering Teardown
The engineering companion to the strategic piece on local inference, deliberately exhaustive. llama.cpp build flags for Blackwell, VRAM accounting to the MiB, context ceilings per quantization, prefill and decode throughput with and without MTP, a roofline analysis of why speculative decoding helps this MoE, a 200-call agentic tool-calling harness, and an autopsy of a KV-cache compression technique that crashed with its CUDA stack trace. Every figure measured on one fixed rig. Continua a leggere
Ultima modifica:
Configurare il caching del browser via .htaccess è ancora una leva di performance reale, ma la ricetta "ExpiresByType, un mese per immagini, CSS e JS" che gira da anni oggi fa più danni che bene: ti serve un utente con il CSS vecchio per un mese dopo ogni deploy. La verità è che il problema non si risolve con la durata della cache, ma con il nome dei file. Vediamo perché Cache-Control ha superato Expires e come si scrive una configurazione di caching insieme aggressiva e sicura. 
OPcache è la singola ottimizzazione PHP con il maggiore impatto sulle prestazioni: su una applicazione Laravel media, la configurazione corretta riduce il tempo di risposta del 40-60%. Ma la configurazione di default non è ottimale per la produzione. Vi mostro i parametri che cambio sempre e perché. 
Un portale di notizie Laravel con 50.000 utenti al giorno mandava in ginocchio il database MySQL ogni volta che arrivava un articolo virale. Ho implementato tre livelli di cache: in-process (array driver), Redis per i dati di business, Nginx proxy cache per le risposte HTTP. Il database ora riceve il 3% delle richieste originali. 
La build Docker di un'applicazione Laravel richiedeva 8 minuti ogni volta. Con l'ottimizzazione del layer caching (dipendenze Composer separate dal codice applicativo), multi-stage build e l'immagine finale Alpine, siamo scesi a 90 secondi. Il CI è diventato abbastanza veloce da aspettare il feedback. 
Durante un Black Friday, l'applicazione e-commerce di un cliente ha saturato i worker PHP-FPM in 90 secondi: 502 Bad Gateway per tutti. Il problema non era la CPU o la RAM, ma la configurazione del pool FPM con pm.max_children troppo basso. Vi mostro il processo di tuning che ho usato per non ripetere l'errore. 
Un'applicazione di reportistica con 50 query analitiche complesse che rallentavano le operazioni transazionali. Con CQRS ho separato i modelli di lettura da quelli di scrittura: le query analitiche usano read model denormalizzati aggiornati asincronamente, le operazioni transazionali volano sul modello normalizzato. 
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. 
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. 
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.