Dietro le Quinte: Massiccia Ottimizzazione delle Prestazioni su Uptime4.com

Abbiamo riscritto parti chiave del sistema. Meno memoria, più velocità, migliore resa con molti dati.

Uptime4.com vive su una promessa semplice: farvi vedere i problemi prima che diventino incidenti. Questa promessa passa da un dettaglio spesso invisibile. Il tempo che serve al browser per mostrare i dati. Quando un nodo cade o un DNS cambia, ogni secondo conta. Se la pagina impiega troppo a caricare, perdete tempo operativo. Negli ultimi mesi abbiamo lavorato su un obiettivo chiaro. Rendere la piattaforma più rapida e più leggera quando i dati sono tanti.

Abbiamo ricostruito parti del codice che gestiscono prestazioni e uso di memoria. Il lavoro riguarda la fase di calcolo e la fase di resa a schermo. Il risultato è un sistema che regge meglio carichi grandi. Parliamo di account con molti monitor, lunghi storici, grafici densi. Parliamo anche di pagine pubbliche con molti eventi e periodi lunghi. Il lavoro è in rollout graduale. Una parte è già attiva su vari account.

Questo aggiornamento non cambia solo l’aspetto. Cambia il modo in cui i dati scorrono nel prodotto. Alcune viste ora caricano in modo più progressivo. Alcune liste ora mostrano solo ciò che serve, quando serve. Alcuni calcoli ora avvengono in modo più efficiente. In test interni su set di dati grandi, abbiamo visto due effetti costanti. Uso di memoria più basso del 20–40%. Tempi di carico più rapidi del 10–25%.

"Su grandi set di dati abbiamo visto -20–40% memoria e -10–25% tempi di carico. Sono misure ripetute su più scenari interni."

Questi valori variano per browser, rete e tipo di dati. Restano un buon indicatore del trend. L’obiettivo non è il numero fine a sé stesso. L’obiettivo è ridurre blocchi e rallenti durante l’analisi. L’obiettivo è tenere la scheda aperta tutto il giorno senza peso inutile. Questa è una parte vitale del lavoro di chi gestisce sistemi.

Perché serviva questo intervento

Negli ultimi mesi è cresciuta la “densità” dei dati in molti account. Più monitor, più metriche, più controlli, più storico. Ogni pagina deve fare più lavoro. Deve scaricare dati, ordinarli, filtrarli, mostrare grafici, mostrare tabelle. Se quel lavoro è fatto male, il browser usa molta RAM. Se usa molta RAM, la pagina diventa lenta. Se diventa lenta, aumentano errori e frustrazione.

Abbiamo osservato un pattern comune. Le pagine più pesanti erano quelle con molte righe e molti grafici. Un esempio tipico è una pagina monitor con centinaia di elementi. Un altro esempio è un server monitor con metriche fitte su molti giorni. Un altro esempio è un DNS monitor con risposte da più aree. In queste viste, piccoli sprechi diventano grandi. Un oggetto in più replicato mille volte pesa. Un calcolo ripetuto ad ogni render pesa. Un grafico che disegna tutti i punti pesa.

Abbiamo scelto una via netta: riscrivere i punti critici. Non un “tocco” superficiale. Una revisione mirata delle parti che creano carico. Il lavoro è stato diviso in tre aree. Trasporto dei dati, calcolo lato client, resa a schermo. Ogni area ha avuto interventi specifici.

Dove si applicano le ottimizzazioni

Le ottimizzazioni descritte in questo articolo si applicano ai seguenti moduli:

• Public status pages: pagine pubbliche di stato e storico incidenti.
• Monitor pages: viste elenco monitor, filtri, stato, dettagli.
• Heartbeat pages: cron, job, ping frequenti e loro storico.
• DNS monitor: query, risposte, tempi, confronto tra location.
• Server monitor: CPU, RAM, disco, rete, grafici e trend.

Il guadagno è più evidente quando i dati sono tanti. È una regola pratica. Se avete pochi monitor, vedrete una pagina più “scorrevole”. Se avete molti monitor, vedrete un salto più grande. Il salto riguarda carico iniziale, reattività dei filtri, scorrimento liste. Riguarda anche la stabilità della scheda nel tempo.

Cosa abbiamo cambiato: una panoramica tecnica, in parole semplici

Un problema tipico delle app web è il “render” eccessivo. Il browser ridisegna parti della pagina troppe volte. Ogni ridisegno richiede calcoli e memoria. Abbiamo ridotto questi ridisegni. Abbiamo reso più stabile la struttura dei dati in memoria. Abbiamo limitato duplicazioni e copie inutili. Abbiamo reso più pigro il carico di sezioni non visibili.

Abbiamo fatto anche un lavoro sui grafici. I grafici sono spesso il punto più costoso. Quando disegnate migliaia di punti, il costo sale in fretta. Abbiamo introdotto una logica di riduzione intelligente dei punti visibili. Lo scopo è mostrare la forma del dato, senza disegnare ogni singolo punto. Quando fate zoom, la vista usa più punti. Quando vedete un periodo lungo, la vista usa meno punti. Il significato resta chiaro. Il costo cala.

Altro punto critico: le liste lunghe. Una lista con centinaia di righe può essere pesante. Ogni riga ha testo, icone, stati, pulsanti. Se tutte le righe sono nel DOM, la pagina soffre. Abbiamo introdotto uno scorrimento “virtuale”. La pagina crea solo le righe che vedete. Le altre restano fuori, pronte a entrare quando servono. Questo riduce memoria e carico.

Abbiamo lavorato anche sul peso dei dati trasferiti. Quando serviva, abbiamo ridotto campi non utili in certe viste. Abbiamo reso più efficiente la forma di alcune risposte. Abbiamo reso più selettivo il download. La pagina non deve sempre prendere tutto lo storico. Deve prendere ciò che serve per la vista attuale. Quando cambiate periodo o filtro, la pagina chiede altro, in modo mirato.

Risultati osservati: memoria e tempi di carico

Durante i test interni abbiamo usato scenari realistici. Abbiamo simulato account con molti monitor e lunghi storici. Abbiamo misurato due aspetti. Memoria usata dal tab durante carico e uso normale. Tempo fino a pagina pronta e interattiva. In questi test, su set grandi, abbiamo visto un calo di memoria del 20–40%. Abbiamo visto un calo dei tempi di carico del 10–25%.

Questi valori sono un intervallo, non un numero fisso. Dipendono da molti fattori. Contano browser e versione. Conta la RAM del dispositivo. Conta la rete. Conta la forma dei dati. Conta anche quali widget sono attivi nella vista. Per questo comunichiamo un range. Il punto chiave resta valido. Il carico è più basso. La risposta è più rapida.

Abbiamo anche visto un beneficio meno “misurabile”. Meno micro-blocchi durante lo scorrimento. Meno ritardi quando cambiate filtro. Meno lag quando aprite più schede. Questo è legato al calo di lavoro del main thread. Il main thread è il filo principale del browser. Se lo sovraccaricate, tutto si ferma. Ridurre quel carico migliora l’esperienza in modo netto.

Dettaglio per modulo

Public Status Pages

Le pagine pubbliche devono essere rapide per natura. Sono viste da clienti finali e team esterni. Spesso sono aperte da mobile. Spesso sono condivise in chat durante un incidente. Il rischio principale è l’accumulo di storico. Quando uno status page mostra anni di eventi, il peso cresce. Abbiamo reso più efficiente il modo in cui questi eventi sono caricati e mostrati. La pagina ora può caricare lo storico in modo più progressivo. Questo riduce carico iniziale e memoria.

Abbiamo anche migliorato il modo in cui vengono calcolati riepiloghi e badge. Alcuni calcoli ora sono memoizzati. Significa che non vengono rifatti se i dati non cambiano. Questo riduce lavoro ripetuto. Il beneficio è più visibile su pagine con molte componenti e molte righe.

Monitor Pages

Le monitor pages sono il “cruscotto” di molti team. Qui si passa da panoramica a dettaglio. Qui si filtrano stati, tag, gruppi, tipo monitor. Il problema tipico è una lista lunga. Ogni riga può avere stato, tempi, azioni, grafico mini. Se mostrate 300 righe, il DOM può esplodere. Lo scorrimento virtuale risolve gran parte del problema. Il browser gestisce meno nodi. La memoria scende. La pagina risponde meglio.

Abbiamo ottimizzato anche il filtro. Prima alcune operazioni lavoravano su liste complete ad ogni digitazione. Ora la logica è più parsimoniosa. Il filtro lavora su indici e su dati già normalizzati. Normalizzare significa mettere i dati in una forma stabile e facile da cercare. Il risultato è una risposta più pronta quando cercate un monitor.

Altro punto: aggiornamenti in tempo quasi reale. Se avete molte righe, ogni update può scatenare molti render. Abbiamo ridotto la parte di UI che si aggiorna. Aggiorniamo solo le righe che cambiano. Riduciamo anche l’uso di oggetti nuovi ad ogni update. Questo taglia il lavoro del garbage collector. Il garbage collector è la parte che libera memoria. Se lavora troppo, la pagina scatta.

Heartbeat Pages

Gli heartbeat sono spesso ad alta frequenza. Un job può pingare ogni minuto. Alcuni pingano anche più spesso. Nel tempo, lo storico cresce molto. Le pagine heartbeat devono mostrare sequenze e gap. Devono anche mostrare eventi recenti in modo chiaro. Abbiamo migliorato due cose. Primo, carico progressivo dello storico. Secondo, grafico più leggero con riduzione punti. Questo è utile quando guardate periodi lunghi.

Abbiamo anche lavorato sull’ordinamento e sulla pagina eventi. Prima alcune viste creavano molte strutture in memoria. Ora usiamo strutture più compatte e riusabili. L’effetto è un tab più stabile nel tempo. Questo è utile quando lasciate aperta la pagina durante un turno.

DNS Monitor

Il DNS monitor ha una complessità diversa. Una query DNS può tornare record multipli. Può variare per location. Può cambiare nel tempo durante una migrazione. La UI deve mostrare confronto e tempi. Qui il peso nasce da due fonti. Molte risposte da molte location. Molti record per risposta. Abbiamo rivisto la fase di parsing e la fase di aggregazione. Parte dell’aggregazione ora avviene in modo più efficiente lato server. La UI riceve un dato più pronto, più compatto.

Questo riduce anche un rischio tipico. Il client che deve fare calcoli complessi su JSON voluminosi. Quel lavoro è fragile su device deboli. Portare parte del lavoro lato server rende la vista più uniforme. L’esperienza diventa più simile tra laptop e mobile. Durante un cambio di record critico, questo aiuta a leggere lo stato più in fretta.

Server Monitor

Il server monitor genera molte metriche. CPU, RAM, disco, rete, processi, tempi. Nel tempo, la serie cresce. Le serie temporali sono dati densi. Se provate a disegnare tutto, il browser soffre. Qui abbiamo agito sul motore dei grafici e sul trasferimento. La UI riceve dati più adatti alla vista scelta. Se guardate 24 ore, arrivano dati più fitti. Se guardate 30 giorni, arrivano dati più compatti. Il grafico mantiene il senso, con un costo più basso.

Abbiamo anche reso più efficiente la gestione delle finestre temporali. Cambiare intervallo non deve rifare tutto da zero. Ora riusiamo parte dei risultati. Riduciamo richieste ripetute quando non servono. Questo accorcia il tempo tra click e grafico pronto. L’effetto è chiaro quando confrontate due periodi.

Come abbiamo lavorato: metodo e controlli

Un intervento su prestazioni ha un rischio tipico. Potete rendere più rapida una cosa e rompere un’altra. Per questo abbiamo seguito una sequenza rigorosa. Abbiamo misurato prima e dopo, su scenari ripetibili. Abbiamo isolato colli di bottiglia veri. Abbiamo ridotto interventi “a istinto”. Abbiamo usato strumenti standard di profiling del browser. Abbiamo controllato memory snapshot e tempi di paint.

1. Mappa dei colli di bottiglia: misure su pagine pesanti e azioni comuni.
2. Refactoring mirato:
   1. Scorrimento virtuale per liste lunghe e tabelle dense.
   2. Riduzione punti grafico, con più punti solo quando serve.
   3. Memoizzazione di calcoli ripetuti e dati derivati.
3. Rollout graduale: attivazione progressiva per ridurre rischi e regressioni.

Durante il rollout, monitoriamo errori lato client e lato server. Guardiamo crash, tempi medi, picchi, feedback. Se vediamo un segnale anomalo, fermiamo e correggiamo. Questo rende l’aggiornamento più lento. Rende anche l’aggiornamento più sicuro. Per un prodotto di monitoraggio, la stabilità conta più della fretta.

Cosa cambia per voi, nel lavoro di ogni giorno

Il beneficio più immediato è la rapidità di apertura delle viste. Quando aprite una pagina densa, la UI si carica più spesso senza attese lunghe. Il secondo beneficio è la reattività dopo il carico. Filtri e scorrimento hanno meno scatti. Il terzo beneficio è la stabilità nel tempo. Lasciare la pagina aperta pesa meno sulla RAM. Questo riduce rallenti dopo molte ore.

Per i team che gestiscono molti ambienti, questo conta molto. Spesso avete più schede aperte. Spesso usate più dashboard. Spesso saltate tra incidenti e trend. Ridurre memoria e render rende tutto più “pronto”. Vi permette di concentrarvi sul problema reale. Vi evita di combattere con l’interfaccia nel momento peggiore.

Per gli status page pubblici, l’effetto è anche esterno. I vostri utenti vedono una pagina che si apre più rapida. Vedono uno storico più facile da scorrere. Vedono un prodotto più curato. In caso di incidente, questo riduce confusione e ticket duplicati. Una pagina lenta genera domande inutili. Una pagina pronta aiuta a comunicare meglio.

Compatibilità, impatto e limiti noti

Le ottimizzazioni sono pensate per browser moderni. Chrome, Edge, Firefox, Safari recenti. Il comportamento può variare tra motori. Alcune funzioni di resa hanno limiti su device molto vecchi. In quei casi la UI può tornare a un percorso più semplice. Lo scopo è evitare blocchi. Lo scopo è mantenere la pagina usabile.

Un punto pratico: i grafici “compatti” possono mostrare meno punti in certe viste. Questo è voluto. La vista lunga serve a capire trend, non ogni micro-variazione. Quando serve dettaglio, lo zoom o il periodo breve mostrano più densità. Questo bilanciamento è comune nelle serie temporali. È un compromesso sano tra fedeltà e costo.

Altro punto: il rollout è graduale. Alcuni account vedranno prima le nuove logiche. Altri vedranno dopo. Questo dipende da gruppi di rilascio e controlli interni. Se notate una differenza tra due account, può dipendere da questo. Con il tempo, l’aggiornamento diventerà lo standard per tutti.

Perché questo lavoro apre la strada a nuove funzioni

Quando una piattaforma diventa più leggera, si libera “spazio” per nuove viste. Spazio in termini di tempo e memoria. Spazio per gestire più dati senza soffrire. Questo è il punto strategico di questo intervento. Non è un fine, è una base. Permette di lavorare su richieste comuni senza rendere la UI pesante.

Ci sono aree dove questo aiuta in modo diretto. Più filtri e raggruppamenti nelle liste. Più dettaglio nei grafici su periodi selezionati. Pagine pubbliche con riepiloghi più ricchi. Analisi più comode su incidenti lunghi. Sono direzioni possibili, non promesse a data fissa. La base tecnica ora regge meglio questi casi.

Per i team con grandi volumi, la scalabilità del client è spesso il limite vero. Il server può calcolare molto. Se il client non riesce a mostrare, il valore è perso. Ridurre carico nel browser è la chiave per crescere. Questo è il senso profondo dell’aggiornamento.

Come potete aiutarci: feedback utile e segnali da inviare

Il feedback migliore è concreto. Indicate la pagina e l’azione. Indicate il browser e la versione. Indicate se avete molti monitor o poco storico. Se potete, indicate l’ora e un esempio. Se vedete un blocco, descrivete cosa accade. Se vedete un grafico “strano”, dite su quale periodo. Questo ci permette di isolare il caso.

Un segnale utile è anche il confronto prima e dopo. Se notate che una vista ora apre più rapida, ditelo. Se notate un punto ancora lento, ditelo. Alcuni colli di bottiglia emergono solo su dati speciali. Un esempio è un DNS con molte risposte diverse. Un altro esempio è una lista con molti tag e filtri. I vostri casi reali sono preziosi.

Riassunto finale

Abbiamo ricostruito parti del codice legate a prestazioni e memoria. Il lavoro tocca status page, monitor pages, heartbeat, DNS monitor, server monitor. Il guadagno cresce con la quantità di dati. In test interni su set grandi, abbiamo visto -20–40% memoria e -10–25% tempi di carico. Il rollout è graduale e controllato. L’obiettivo è chiaro: pagine più rapide, tab più stabile, analisi più fluida.

Questo aggiornamento è un investimento tecnico e operativo. Riduce attrito nel lavoro quotidiano. Migliora la qualità della risposta durante incidenti. Prepara la piattaforma a funzioni più ricche, senza peso inutile. Grazie per l’uso quotidiano di Uptime4.com. Grazie anche per i feedback che ci inviate.