Ottimizzazione degli intervalli di validità delle risorse su RD

Analizzare soltanto il tempo necessario per il completamento delle operazioni non restituisce un quadro dettagliato della situazione in cui si troverà il dispositivo successivamente.

Per questo motivo è stato utilizzato il profiling tramite VisualVM: per verificare che non ci siano complicazioni nel caso si vogliano effettuare altre operazioni. Ed è tramite il profiler che è stato trovato un altro problema nell’implementazione standard di Californium.

Questa è la situazione della CPU e della RAM dopo aver eseguito vari POST, con circa 500 risorse da 4 attributi caricate:

elevato su un dispositivo come il Raspberry Pi.

Cercando di effettuare altri test la situazione peggiora drasticamente: analizzando il quadro dei thread attualmente utilizzati:

Notiamo che sono presenti circa 570 thread attivi che rendono il dispositivo inutilizzabile.

Per capire perché in presenza di un quantitativo alto di risorse salvate nella RD abbiamo questo comportamento bisogna prima descrivere il contenuto dello standard e come è stato implementato nel progetto Californium: ogni volta che viene inserita una risorsa viene associato un thread per il controllo della scadenza della stessa.

Come definito nella RFC della Resource Directory ogni entry deve avere un intervallo di validità dopo il quale bisogna rimuoverla in modo tale da gestire anche quei nodi che si disconnettono prima di inviare un messaggio DELETE al broker.

Infatti analizzando il codice all’interno di un ResourceNode è presente una classe interna Runnable che esegue la rimozione della risorsa una volta eseguito il timer associato.

È una soluzione che si sposa benissimo con il contenuto della RFC ma, naturalmente, nel caso siano presenti un numero elevato di nodi otteniamo prestazioni inaccettabili dato che il

numero di thread aumenta proporzionalmente al numero di broker che effettuano la POST.

Se si vuole rimanere conformi allo standard l’implementazione con thread associato ad ogni nodo è la più corretta possibile. È importante, nel nostro caso e in generale nelle situazioni con un elevato numero di nodi, cercare di rendere il dispositivo il più veloce possibile ma anche ridurre il consumo di memoria cercando di restare quanto più possibili vicini alle

direttive dello standard.

I requisiti che si vogliono soddisfare per il supporto sono: 1. Ridurre l’overhead dato dall’enorme numero di thread.

2. Consentire una certa flessibilità nella scelta della precisione dell’intervallo di validità delle risorse su un nodo.

3. Avere comunque un meccanismo di rimozione dei nodi che sono presenti per più di un certo periodo di tempo.

4. L’associazione di un intervallo temporale deve avvenire velocemente, altrimenti si rischia di rallentare tutta l’operazione di POST.

L’associazione di un intervallo temporale (con eventuale modifica) è una di quelle operazioni che se effettuate con il metodo standard di Java consuma un numero elevato di cicli di clock. Esiste un framework chiamato Joda Time che ormai è lo standard de facto per tutte le operazioni di creazione e di modifica di date. È molto più veloce ed efficiente della normale implementazione Java (della JDK 7 dato che nella versione 8 è stata praticamente integrata in modo nativo questa libreria).

Per quanto riguarda il primo punto possiamo implementare un meccanismo più lasco rispetto a quello con thread per ogni nodo: invece di considerare una delete associata ad ogni risorsa utilizziamo un thread generico per la Resource Directory che dopo ogni intervallo effettua una pulizia di quelle scadute.

In genere non è così importante essere precisi al secondo. La data di validità di ogni risorsa con questo nuovo tipo di approccio può essere quindi considerata nel worst case come:

Data attuale + intervallo di validità + MAX(intervallo di aggiornamento del thread)

Facciamo un esempio:

• Una risorsa è stata aggiunta alle 12:30:00 con un intervallo di scadenza di 30 secondi. La data di scadenza è quindi alle 12:30:30.

• Consideriamo l’intervallo di aggiornamento del thread di rimozione pari a 60 secondi con l’ultima esecuzione effettuata alle 12:30:29.

• La risorsa verrebbe rimossa alle 12:31:29 secondi anche se è scaduta ben 59 secondi prima.

la reattività nella cancellazione delle risorse scadute.

Una considerazione legata al punto 4 è che se esiste questo thread di controllo è importante anche capire velocemente se la data di scadenza è situata cronologicamente prima della data di controllo. È anche per questo motivo che è stata scelta Joda Time, che risulta essere molto performante in questo tipo di operazioni.

Nel nostro caso non è così importante avere sempre le risorse aggiornate al millisecondo nella Resource Directory in quanto al massimo se non è più disponibile non restituirà un risultato e si perderà soltanto una chiamata CoAP che di per se è molto leggera dato che è stata

progettata per essere utilizzata in ambito IoT.

Un’altra scelta fatta è quella di non inserire il controllo della scadenza nel metodo di risposta REST dato che si andrebbero a rallentare le operazioni più semplici, che vengono effettuate un numero di volte molto alto.

Dopo aver implementato i metodi appropriati e rieseguendo il test su 500 risorse come nel caso precedente otteniamo questa situazione:

Il consumo di CPU è nettamente diminuito, così come quello di memoria che ora è più di 3 volte inferiore rispetto all’implementazione standard.

Ma soprattutto il numero di thread dopo l’esecuzione delle POST rimane praticamente identico:

Questo tipo di soluzione ripagherà molto anche successivamente, quando si andranno ad analizzare le performance per le operazioni di lookup locale.