Cloudflare introduce il profiling CPU e memoria per Workers in produzione

Cloudflare ha aggiunto il profiling on-demand di CPU e memoria per Workers e Durable Objects in produzione. L'annuncio, pubblicato sul blog ufficiale il 9 ottobre 2026, riguarda chi ha già sentito l'errore 1102 ("Worker exceeded resource limits") e finora doveva indovinare la causa guardando log e metriche aggregate.

Cosa fa in pratica

Oggi annunciamo il supporto per il profiling CPU e memoria di Workers e Durable Objects. Dalla pagina Workers Observability si può ora richiedere un profilo CPU o memoria on-demand di un Worker attivo, ispezionarlo come flamegraph interattivo e scaricare il file del profilo per analisi ulteriori. Il punto tecnico interessante è che il profiling avviene su un isolate già in esecuzione, con traffico reale: il runtime Workers mantiene il lock dell'isolate solo brevemente durante le operazioni di avvio/stop del profiler, non per tutta la durata. Acquisisce il lock per avviare un profiler CPU V8 che campiona a intervalli di un millisecondo, lo rilascia così le richieste continuano a essere processate, aspetta la durata richiesta, poi riacquisisce il lock solo per fermare il profiling e serializzare i risultati.

Come attivarlo

Da dashboard: si va nella pagina Workers dell'account, si seleziona il Worker, si apre la scheda Observability e si usa il menu a tendina per scegliere "Flamegraph". Da riga di comando il comando è:

cf workers versions profile latest \
 --worker-id "$WORKER_ID_OR_NAME" \
 --duration-ms 5000 \
 --profile-type cpu > worker-cpu.pprof

Un dettaglio da non sottovalutare: il Worker ha bisogno di traffico sufficiente per essere profilato con successo, quindi conviene scegliere una versione che riceve abbastanza traffico. Se il codice è in TypeScript, Cloudflare segnala di attivare le source maps, altrimenti il flamegraph mostra nomi di funzione offuscati.

Il caso interno: da 133 MB a 118 MB

Cloudflare ha usato lo strumento sul proprio Worker che gestisce il binding R2. Profilando la CPU ha trovato una funzione di replace JSON ricorsiva che attraversava ripetutamente dati annidati, facendo lavoro ridondante; correggendo l'implementazione è diventata, secondo quanto dichiarato, 2,7 volte più veloce. Sul fronte memoria, un altro Worker interno aveva un problema più insidioso: la memoria al percentile P999 si attestava intorno ai 133 MB contro il limite di 128 MB per Worker, causando l'evizione frequente con errore "Exceeded Memory". Il profilo heap ha rivelato che il codice Prometheus rappresentava circa il 66,7% delle allocazioni nel profilo, codice che avrebbe dovuto essere disabilitato ma che in parte girava ancora. Rimosso quel codice, la memoria P999 è scesa da 133 a 118 MB.

Perché conta per chi paga quei server

Il profiling non cambia i limiti, aiuta solo a starci dentro. Sul piano Free il tetto resta 10 ms di CPU per richiesta HTTP e non è alzabile; sul Paid il default è 30 secondi, configurabile fino a 300.000 ms (5 minuti) tramite limits.cpu_ms in wrangler. La memoria resta fissa a 128 MB per isolate su entrambi i piani. Chi gestisce Worker in produzione con errori exceededCpu o exceededMemory ricorrenti nei log può ora catturare un profilo reale invece di modificare codice a tentativi.

Prime Server, Koapanel, KoaVM e Koabilling non sono coinvolti in questo annuncio: è una funzione nativa della piattaforma Cloudflare Workers.