Simula cittadini su chat e censimento. Le paline vere si
accendono dalla pagina flotta: qui non se ne creano di finte.
ResiLnet
Cosa fanno i campi
Cittadini
Quante sessioni simulate aprire. Ognuna e' una connessione XMPP vera,
con la sua autenticazione e il suo ingresso in stanza: e' questo il costo
che stiamo misurando. Entrano poco alla volta, non tutti insieme.
Sali per gradini — 100, 300, 600, 1000 — per trovare DOVE si piega,
non per verificare se regge un numero grande.
Un messaggio ogni (s)
Ogni quanti secondi, in media, un cittadino scrive in chat. 60 e' un
ritmo verosimile; abbassarlo a 10 non simula piu' persone reali ma
mette sotto sforzo la stanza e il ponte, che e' un'altra prova.
Il valore vero varia del 50% in piu' o in meno, perche' persone che
scrivono tutte allo stesso istante non esistono.
Paline
Codici separati da virgola (es. AT0001,AT0004).
Lasciandolo vuoto si usano tutte quelle del sistema.
Attenzione pero': in un'emergenza vera le persone NON si distribuiscono
in parti uguali su 33 aree, si concentrano nelle poche vicine e nelle
aree di accoglienza grandi. Spalmare 500 cittadini su tutte le paline e'
uno scenario piu' gentile del vero, perche' divide il carico; metterne
500 su cinque paline mette alla prova cio' che conta davvero — la stanza
unica, la coda dell'operatore, la console di chi segue quelle aree.
Durata massima (min)
Dopo questo tempo la prova si ferma da sola, ingresso dei cittadini
compreso. 0 = nessun limite. Serve a confrontare gradini
diversi a parita' di durata, e a non lasciare una prova accesa per
dimenticanza. I numeri restano visibili dopo l'arresto.
Picchi d'uso
In un'emergenza vera il traffico non e' piatto. Con i picchi attivi,
in istanti casuali (in media ogni 10 minuti se occasionali, ogni
4 se frequenti) arriva una scossa di assestamento — tutti
scrivono insieme, di colpo, da 6 a 10 volte il ritmo, con molte richieste
"sto bene" e "cerco" — oppure una comunicazione ufficiale, che fa
salire il traffico di 3-5 volte in modo piu' graduale, con domande piu'
che richieste. Ogni picco compare fra gli avvisi: confrontalo con quello
che segnala il ponte nello stesso momento.
I due tratti del ritardo
Il ritardo totale non dice CHI ha ritardato. Si divide percio' in due:
sistema (dall'invio del cittadino al momento in cui il ponte
tratta il messaggio: e' ejabberd piu' il ponte) e generatore (dal
ponte a quando questa pagina legge il messaggio dal bus). Se il secondo
e' alto, a essere lento e' lo strumento di misura, non il sistema: con
diecimila cittadini da creare il generatore e' occupato, e il suo
ritardo di lettura finirebbe altrimenti addebitato al sistema.
Ritardo ed eco
Il ritardo va dall'invio del cittadino all'arrivo del messaggio
sul bus, cioe' passa per ejabberd, ponte e broker. L'eco esisteva
quando i cittadini scrivevano in stanza (ogni messaggio tornava anche a
chi l'aveva scritto). Con lo sportello si scrive diretti al ponte, non
c'e' piu' eco e quel numero resta vuoto: e' normale.
Ingresso in (s)
0: i cittadini entrano uno alla volta (circa uno ogni
0,15 s). Con un numero, per esempio 20, entrano TUTTI in
quei secondi, con le credenziali chieste in parallelo: e' il minuto dopo
una scossa, quando tutti prendono il telefono insieme. Il numero
ingresso completato dice in quanto tempo l'ultimo e' davvero
dentro: se e' molto piu' lungo della finestra scelta, il sistema non
regge l'arrivo di massa.
Archivio all'ingresso
La chat vera, appena entrata, chiede le ultime voci della propria
conversazione e della bacheca (le ricerche aperte). Con la casella
spuntata lo fa anche il generatore, e i tempi compaiono separati:
archivio bacheca lo serve la stanza, che e' un processo solo,
e con un ingresso di massa lo chiedono tutti insieme.
Richieste (%)
Quota dei messaggi che sono richieste tipizzate (medicine, assistenza,
cerco, sto bene) invece di chiacchiera. E' la quota "in calma": durante
una scossa sale fino a due volte e mezza, durante un annuncio scende.
Richiesta o messaggio normale e' deciso a caso, messaggio per messaggio.
I cittadini non sono uguali: pochi scrivono molto, molti quasi mai, come
in qualunque chat vera; il ritmo impostato resta la media.
Operatori
0 = nessuno: la coda cresce e basta, come finora. Con un
numero, altrettanti operatori simulati smaltiscono le richieste come
farebbero le persone in sala — passano SOLO dal bus MQTT, con lo
stesso percorso della console dell'operatore (presa in carico,
risposta, chiusura), in ordine di gravita' (assistenza prima di
medicine, le piu' vecchie prima a parita' di categoria) e una
richiesta alla volta a testa. Servono a scoprire se il sistema regge
meglio quando la coda non si accumula senza fine.
Secondi per richiesta
Tempo medio di lavorazione di un operatore simulato, dalla presa in
carico alla risposta. Varia a caso attorno a questo valore (da meta'
a una volta e mezza: 40 vuol dire fra 20 e 60 secondi),
perche' operatori veri non impiegano tutti lo stesso tempo.
Fibra tagliata (%)
0 = nessuna: come oggi. Con un numero, quella percentuale
delle paline USATE in questa prova (non di tutte quelle esistenti)
perde la fibra all'avvio e resta in LoRa per l'intera durata: lo stesso
taglio che si farebbe a mano da "Taglia fibra" nel centro comando,
pubblicato sullo stesso comando. Il ripristino e' automatico quando la
prova si ferma, sia a scadenza sia manualmente. Serve a vedere il
fallback radio (duty cycle, paline in LoRa) sotto lo stesso carico di
chat, invece di doverlo provare a parte con poche paline alla volta.
Apri e chiudi un'emergenza di prova
Prima di far entrare i cittadini il generatore apre un'emergenza
«Prova di carico gg/mm hh:mm:ss», come farebbe il direttore delle
operazioni: il ponte cancella tutto (come «Cancella dati di prova»),
apre il registro della prova e la Mappa 3D avvia il suo evento. A fine
prova, dopo le verifiche, la chiude. Il ponte lascia al generatore
SOLO le emergenze aperte da lui: se e' aperta un'emergenza vera la prova
non parte. Se ne trova una di prova rimasta aperta (codice ricaricato a
meta'), la chiude prima. Servono i permessi dell'utente carico
sul bus (firmato/carico/emergenza e /archivi).
Elimina l'archivio a fine prova
Di serie NON spuntato: l'archivio della prova resta, e si guarda dal
centro comando (Scarica e verifica). Gli archivi delle prove li toglie
comunque «Cancella dati di prova» (o «Cancella tutto»), anche sulla Mappa
3D. Spuntato: dopo la chiusura l'archivio si elimina subito, e con lui
l'evento sulla Mappa 3D e le sue voci. Attenzione: la mappa elimina anche
l'evento d'archivio «Prima dell'emergenza…» creato all'apertura, cioe' le
voci del registro della mappa scritte fuori evento prima della prova.
Operatori mappa / Un'azione ogni (s)
Operatori simulati sulla Mappa 3D, solo dentro l'emergenza di prova e
solo dopo che la mappa ha avviato l'evento. Ognuno, in media ogni tanti
secondi, fa cio' che farebbe una persona in sala: segnala una strada
interrotta o un pericolo su una via vera attorno al centro, cambia una
sua segnalazione (interrotta/pericolo) o segna la strada riaperta,
aggiunge una segnalazione dal campo (danno, pericolo, sopralluogo,
informazione), scrive una nota nel registro con la posizione, consulta
registro e interruzioni. Stesse chiamate della pagina della mappa. Le
segnalazioni hanno la proprieta' prova e a fine prova si
tolgono TUTTE, prima di chiudere l'emergenza.
Con foto
Ogni segnalazione dal campo arriva con una foto, come «Foto dal campo»
nella mappa, e circa un terzo delle strade interrotte anche. Sono foto di
PROVA (scritte in chiaro), da ~370 KB come quelle che la pagina della mappa
riduce prima dell'invio, scaricate dal web di ResiLnet
(/prove_foto/). A fine prova si eliminano prima delle
segnalazioni: la mappa le sposta nel suo cestino.
Utente / Password mappa
Un utente ResiLnet da operatore (la mappa accetta solo utenti
ResiLnet). Si scrivono una volta e «Salva credenziali» le mette in
carico_mappa.env accanto a carico.py, leggibile solo dal
proprietario; in alternativa le variabili MAPPA_UTENTE e MAPPA_PASSWORD.
Sirene / Flash / Testi ai LED accesi (%)
Tre comandi indipendenti, ciascuno con la sua percentuale: 0
vuol dire che quel comando non parte affatto. Con un numero, quella
percentuale delle paline USATE in questa prova (scelta a caso per
ciascun comando separatamente) riceve all'avvio lo stesso comando che
partirebbe da "Attiva sirena"/"Attiva flash"/il campo del pannello LED
in gui/command_center.html — stesso topic, stessa forma.
Sirena e flash si spengono, il testo LED si cancella, quando la prova
si ferma (a scadenza o a mano). Le paline scelte possono capitare
anche fra quelle in LoRa (tagliate qui sopra o gia' giu' per conto
loro): il comando parte comunque sullo stesso topic, ci pensa
lora_gateway.py a instradarlo via radio, cosi' si mette
alla prova anche quel percorso sotto lo stesso carico di chat.
Confronto col test precedente
Ritardo operatore — la misura che conta
Cosa vuol dire
Ritardo mediano / 90° perc. / peggiore
Quanto passa dall'invio del cittadino alla comparsa del messaggio sul
bus (ejabberd + ponte + broker). Il mediano e' il caso tipico, il 90°
percentile mostra la coda che il mediano nasconde, il peggiore e' il
caso limite di questa prova. Non e' il tempo di lavoro dell'operatore:
quello e' nella sezione Operatori qui sotto.
In ritardo oltre 10 s / Persi davvero
Durante la prova: messaggi non ancora comparsi sul bus dopo 10 secondi
dall'invio. Sono in RITARDO, non persi: possono ancora arrivare, e in
una prova a 10.000 sono arrivati (il conteggio sale e poi scende).
A fine prova il ponte conferma chi ha in archivio; solo allora compaiono
persi davvero (mai arrivati al ponte) e solo eco di misura
persa (arrivati al ponte, buco nell'eco). persi_elenco
(sotto, fra gli avvisi) dice CHI e COSA, per cercarlo nei log del ponte.
In volo
Messaggi gia' inviati di cui non si e' ancora vista ne' la comparsa
ne' i 10 secondi che li farebbero contare come persi.
Fermati dall'argine / silenziati ora
Non sono ritardo: sono la moderazione automatica del ponte
(_controlla_inondazione) che toglie la parola a chi manda
troppi messaggi in poco tempo. Restano qui perche' li calcola la
stessa classe che misura il ritardo, non perche' siano lavoro
dell'operatore.
Tratti del ritardo (dove si forma la coda)
Cosa vuol dire
Tabella per fascia (Partiti fra)
Lo stesso ritardo invio→ponte diviso per momento di PARTENZA
(fasce da 30 s). Dice quando nasce la coda: durante l'ingresso, al
picco di invii o dopo. inviati/s e' il ritmo con cui il
generatore ha davvero spedito: se salta all'improvviso, i messaggi
sono partiti a ondate. Il ritardo e' calcolato solo sui messaggi gia'
arrivati, quindi le fasce recenti si assestano col tempo.
Sistema 90° / peggiore (invio→ponte)
Quanto ci mettono ejabberd e il ponte a trattare il messaggio. Se
sale, e' li' che vale la pena guardare per primi.
Generatore 90° / peggiore (lettura dal bus)
Quanto ci mette QUESTA pagina a leggere il messaggio dal bus una
volta che il ponte l'ha gia' pubblicato. Se questo e' alto, e' lo
strumento di misura a essere occupato (migliaia di cittadini da
creare), non il sistema sotto prova.
Eco xmpp mediano / 90° perc.
Andata e ritorno di un messaggio scritto IN STANZA. Con lo sportello
(un cittadino scrive diretto al ponte) non c'e' piu' eco: resta vuoto,
ed e' normale.
Ingresso cittadini
Cosa vuol dire
In stanza / avviati
Sessioni davvero entrate in stanza adesso, su quante la prova ha
tentato di aprirne in totale.
Ingresso completato
Da quando la prova e' partita a quando l'ULTIMO cittadino e' entrato
davvero. Molto piu' lungo della finestra scelta in "Ingresso in (s)"
vuol dire che il sistema non regge l'arrivo di massa.
Credenziali fallite / al 2° tentativo, ingressi falliti
Autenticazione o ingresso XMPP non riusciti al primo colpo (o mai).
Archivio all'ingresso
Cosa vuol dire
Archivio bacheca / personale 90°
Tempo per ricevere, al primo ingresso, la cronologia della bacheca
(ricerche aperte, servita dalla stanza — un processo solo) e della
chat personale con lo sportello.
Archivi falliti
Richieste di una delle due cronologie rimaste senza risposta.
Operatori
Cosa vuol dire
Operatori simulati configurati
Il numero messo nel campo "Operatori" per questa prova (0 = nessuno,
la coda cresce e basta).
Richieste prese in carico / risposte inviate / richieste chiuse
Cosa hanno davvero lavorato gli operatori — simulati, o anche un
operatore vero in console sulla stessa coda.
Attesa in coda mediana / 90° perc.
Da quando una richiesta si apre a quando qualcuno (simulato o vero)
la prende in carico.
Richieste in coda ora
Quante restano aperte o in lavorazione in QUESTO istante, anche a
prova finita: dice se la coda si e' svuotata o e' rimasta li'.
Emergenza e Mappa 3D
Cosa vuol dire
Apertura (s)
Dal comando all'esito del ponte: comprende la cancellazione di tutti i
dati e degli account dei cittadini della prova precedente.
Mappa 3D
La risposta della mappa («evento avviato», poi «evento chiuso») e
quanti secondi dopo l'apertura e' arrivata. Senza risposta gli operatori
della mappa non partono.
Azioni sulla mappa / fallite / risposta
Chiamate all'API della mappa fatte dagli operatori simulati, e il
tempo di risposta. Le fallite devono restare 0: il dettaglio degli
ultimi errori e' qui sotto.
Segnalazioni attive / lasciate / tolte a fine prova
Quelle della prova ancora sulla mappa. Di norma a fine prova
restano («lasciate sulla mappa»): le toglie la mappa quando
ResiLnet elimina l'archivio dell'emergenza di prova («Cancella tutto»,
«Cancella dati di prova»), solo quelle con la proprieta'
prova create in quell'evento. Con «togli dalla mappa a fine
prova» le toglie il generatore: allora «non tolte» deve essere 0.
Ricongiungimenti
Cosa vuol dire
Ricerche aperte / pubblicate
Il ponte pubblica al piu' 300 schede, scelte per importanza: prima
le "da vedere", poi le presenze verificate, poi le corrispondenze
esatte, poi le piu' recenti. Meta' delle ricerche simulate cerca nome
e cognome di un censito simulato, quindi trova corrispondenze.
Presenze verificate / "da vedere" dopo
La sala simulata verifica di persona, al ritmo del campo
"Verifiche/min", una corrispondenza esatta presa dalle schede
pubblicate. Si misura quanto passa fino a quando la ricerca compare
"da vedere" nell'elenco pubblicato. Le schede di prova non mandano
avvisi in console.
Elenchi fuori ordine
Elenchi pubblicati NON in ordine di importanza: deve restare 0.
Ricerche oltre le 300
Ogni 10 s si cerca il nome di chi ha aperto una ricerca che non e'
piu' fra le pubblicate, come fa il filtro della pagina: "trovate"
vuol dire che il ponte l'ha restituita. Mancate e senza risposta
devono restare 0.
Controllo finale
A prova finita, per al piu' 10 nomi verificati: nessuna ricerca
rimasta fuori dalle pubblicate deve essere piu' importante
dell'ultima pubblicata. Le violazioni devono essere 0.
Censimento e spostamenti
Cosa vuol dire
Nomi
Ogni cittadino simulato ha un nome e cognome suo (120 nomi x 130
cognomi), salvo una piccola quota di omonimi voluti. Le ricerche
"Nome Cognome" cercano nomi di cittadini della prova.
Spostamenti
Una quota di cittadini a meta' prova va in un altro punto di raccolta
e si registra di nuovo con lo stesso telefono. Il ponte deve aggiornare
la sua scheda (una sola, con lo storico e la verifica da rifare), non
crearne una seconda.
Schede nel censimento / attese
A prova finita: le schede devono essere quelle di prima piu' una per
cittadino. Di piu' vuol dire che uno spostamento ha creato una scheda
nuova.
Elenchi per punto completi
A prova finita, per 3 punti a caso: l'elenco completo del punto deve
avere tante schede quante ne conta il ponte.
Ricerche nel censimento intero
Ogni 15 s si cerca per nome uno dei primi cittadini entrati (non piu'
fra le ultime 3.000 schede pubblicate): "trovate" vuol dire che il
ponte l'ha restituito. Mancate e senza risposta devono restare 0.
Spostati controllati / corretti
Fra le schede pubblicate (le ultime 3.000), quelle di chi si e'
spostato: devono stare nel punto nuovo, con lo spostamento nello
storico.
Rete LoRa (taglio fibra)
Cosa vuol dire
% configurata per questa prova
Il valore messo nel campo "Fibra tagliata (%)" — 0 vuol dire che
nessuna palina e' stata toccata da questa prova.
Paline tagliate da questa prova
Quante ne ha scelte e tagliate QUESTA prova all'avvio (si
ripristinano da sole quando si ferma).
Paline in LoRa ora (gateway)
Cio' che il gateway LoRa vede DAVVERO in questo momento: puo'
differire dal numero sopra se qualcuno ha tagliato o ripristinato
fibra a mano dal centro comando nel frattempo. Resta "—" se
lora_gateway.py non ha ancora pubblicato nulla.
Duty cycle radio
Percentuale del tempo di trasmissione consumato sul limite EU868
(sotto-banda 869,525 MHz, 10% di un'ora, cioe' 360s/ora): oltre quel budget il gateway mette in
coda i comandi anziche' trasmetterli subito.
Frame trasmessi
Contatore totale di frame LoRa inviati dal gateway da quando e'
acceso (non solo per questa prova).
Comandi (sirene, flash, testi LED)
Cosa vuol dire
% configurata
Il valore messo nei campi "Sirene/Flash/Testi ai LED accesi (%)"
per questa prova — 0 vuol dire che quel comando non e' partito.
Inviate / inviati / inviati
Quante paline ha scelto e comandato QUESTA prova all'avvio (si
spengono/puliscono da sole quando si ferma). Possono includere
paline in LoRa: il comando viaggia sullo stesso topic sia per fibra
che per radio.
Comandi inviati / testi inviati
Somma dei due comandi on/off (sirena+flash) e conteggio a parte
dei testi al pannello LED, che portano un contenuto e non solo uno
stato.
Di cui via radio (frame LoRa) / duty cycle consumato da questa prova
Fra le paline scelte sopra, quante erano DAVVERO in LoRa in quel
momento (via fibra il comando non tocca la radio) e quanto airtime
hanno consumato sul budget EU868 — misurato dal gateway
(lora_gateway.py), per DIFFERENZA fra la sua telemetria
adesso e quella di quando questa prova e' partita: non e' il totale
del gateway da quando e' acceso, e' cio' che ha consumato
questa prova. Il dettaglio per sirena/flash/testo LED separa
chi sta davvero pesando sulla radio. "% configurata" alta con "via
radio" basso vuol dire che le paline scelte erano quasi tutte su
fibra: normale se "Fibra tagliata (%)" e' basso o zero.
Verifica pulizia
Cosa vuol dire
Messaggi/richieste/censimenti/ricerche ancora su SQLite (ponte)
Conteggio VERO delle righe nelle tabelle del ponte
(/dati/ponte.db), non quanto mostra normalmente la
pagina: deve essere 0 se l'ultima "Cancella dati di prova" e'
davvero riuscita. Letto dal battito del ponte, aggiornato ogni
10s.
Messaggi ancora nell'archivio MAM (ejabberd)
Righe rimaste nell'archivio XMPP vero e proprio
(ejabberd.db, tabella archive): e' quello
che "Cancella dati di prova" NON toccava prima, e che degradava le
prove successive quando cresceva troppo. Letto da
monitor_docker.py sull'host, aggiornato ogni 30s (query
piu' pesante delle altre).
MB dei file ejabberd.db / ponte.db
Dimensione su disco dei due database. Non scendono da soli dopo
una cancellazione: SQLite libera le righe ma non restituisce lo
spazio al filesystem senza un VACUUM. Non e' un segno di sporco residuo,
solo di spazio non ancora recuperato.
Traffico generato
Cosa vuol dire
Messaggi inviati / non inviati (sessione caduta)
Quanti il generatore e' riuscito a mandare, e quanti no perche' la
sessione XMPP del cittadino era gia' caduta.
Registrazioni
Censimenti (nome + palina) inviati dai cittadini simulati.
Ritmo e generatore
Cosa vuol dire
Ritmo attuale
Moltiplicatore sul ritmo base, alzato durante un picco (vedi
"Picchi d'uso" fra i campi del modulo).
Saturazione generatore (max)
Quanto e' rimasto indietro IL CICLO DI QUESTA PAGINA, al peggio.
Oltre 1s i ritardi misurati includono il ritardo dello strumento, non
solo del sistema: vedi l'avviso rosso sopra i numeri.
Carico lxc
Load average della macchina che genera il carico, contro quante CPU
ha: se supera le CPU, e' il generatore stesso a essere il collo di
bottiglia.
Avvisi dal sistema
Cio' che il ponte segnala mentre gira:
argine scattato, salvataggio fallito, archivio in crescita. In bianco le
righe della simulazione stessa (inizio dei picchi, arresto). Non sostituisce
docker compose logs -f ponte, che serve per le eccezioni
impreviste — quelle sul bus non passano.
Macchina di ResiLnet
—
Messaggi in ritardo o persi
Partiti ma non ancora arrivati sul bus dopo 10 secondi
(in prova sono in ritardo; a prova finita la verifica dice se sono persi).
Con nome, testo e ora si cercano nella console e nei log del ponte
(docker compose logs ponte | grep "…").
Guasti del generatore
Un elenco vuoto e' il risultato migliore.
Mentre gira, guarda il sistema vero — e' li' che si vedono i problemi:
apri il centro comando e cronometra quanto ci mette;
apri la console chat e prova a prendere in carico una richiesta;
apri il censimento e cerca un nome;
guarda docker compose logs -f ponte e cerca avvisi.
Il numero qui sotto che conta di piu' e' il ritardo operatore: e'
quanto passa fra il messaggio del cittadino e la sua comparsa sul bus.