chore: refactor double quotes
All checks were successful
Build LaTeX Document / build_latex (push) Successful in 3m11s
All checks were successful
Build LaTeX Document / build_latex (push) Successful in 3m11s
This commit is contained in:
106
Tesi.tex
106
Tesi.tex
@@ -543,11 +543,11 @@ Queste metriche possono essere visualizzate attraverso dashboard Grafana o altri
|
||||
|
||||
\chapter{Verifica empirica delle prestazioni P2P di PeerTube}
|
||||
|
||||
A dicembre 2023, il team di PeerTube ha pubblicato un articolo in cui va ad analizzarne le prestazioni facendo degli `stress test' per verificare se la tecnologia P2P integrata nel sistema sia effettivamente in grado di ridurre il carico sui server con circa 1000 utenti connessi contemporaneamente, in quanto, secondo i dati raccolti da Twitch nel 2022, coprivano il 99\% dei casi di utilizzo della piattaforma.
|
||||
A dicembre 2023, il team di PeerTube ha pubblicato un articolo in cui va ad analizzarne le prestazioni facendo degli \textit{stress test} per verificare se la tecnologia P2P integrata nel sistema sia effettivamente in grado di ridurre il carico sui server con circa 1000 utenti connessi contemporaneamente, in quanto, secondo i dati raccolti da Twitch nel 2022, coprivano il 99\% dei casi di utilizzo della piattaforma.
|
||||
|
||||
\
|
||||
|
||||
Per realizzare test veritieri, il team ha simulato 1.000 spettatori simultanei utilizzando 1.000 browser Chrome, ciascuno con un indirizzo IP pubblico IPv6 dedicato. Questo è stato realizzato tramite `Selenium grid', un software di automazione e testing per i browser, affiancato da Docker su cloud Hetzner e successivamente con un potente server fornito da Octopuce.
|
||||
Per realizzare test veritieri, il team ha simulato 1.000 spettatori simultanei utilizzando 1.000 browser Chrome, ciascuno con un indirizzo IP pubblico IPv6 dedicato. Questo è stato realizzato tramite Selenium grid, un software di automazione e testing per i browser, affiancato da Docker su cloud Hetzner e successivamente con un potente server fornito da Octopuce.
|
||||
|
||||
La scelta di 1.000 spettatori è significativa poiché copre la stragrande maggioranza delle dirette streaming su piattaforme importanti come Twitch, suggerendo che PeerTube può essere adeguato per un'ampia gamma di casi d'uso.
|
||||
In condizioni ottimali, l'aspetto P2P di PeerTube dovrebbe ridurre la larghezza di banda necessaria per trasmettere un video in diretta di un fattore da 3 a 4, standa quanto detto degli sviluppatori di PeerTube.
|
||||
@@ -556,10 +556,10 @@ In condizioni ottimali, l'aspetto P2P di PeerTube dovrebbe ridurre la larghezza
|
||||
|
||||
Sono stati condotti 4 scenari di test principali:
|
||||
\begin{itemize}
|
||||
\item Live streaming con impostazione `Normal Latency'
|
||||
\item Live streaming con impostazione `High Latency'
|
||||
\item Live streaming con impostazione `High Latency' e 50\% dei peer con P2P disabilitato
|
||||
\item Un normale video `on-demand'
|
||||
\item Live streaming con impostazione \textit{Normal Latency}
|
||||
\item Live streaming con impostazione \textit{High Latency}
|
||||
\item Live streaming con impostazione \textit{High Latency} e 50\% dei peer con P2P disabilitato
|
||||
\item Un normale video \textit{on-demand}
|
||||
\end{itemize}
|
||||
|
||||
su una macchina virtuale con:
|
||||
@@ -577,7 +577,7 @@ I dati dei test sono stati raccolti tramite OpenTelemetry e Grafana, con metrich
|
||||
\item Numero di spettatori
|
||||
\end{itemize}
|
||||
|
||||
con i quali, infine, sono stati in grado di dimostrare che PeerTube è in grado di gestire 1.000 spettatori simultanei con un carico minimo sui server, grazie alla tecnologia P2P integrata in quanto la quantità di dati trasferiti via P2P è progressivamente aumentata con il tempo fino a raggiungere un rapporto del 75\% dei dati totali trasferiti per i video in diretta e del 98\% per i video `on-demand'.
|
||||
con i quali, infine, sono stati in grado di dimostrare che PeerTube è in grado di gestire 1.000 spettatori simultanei con un carico minimo sui server, grazie alla tecnologia P2P integrata in quanto la quantità di dati trasferiti via P2P, è progressivamente aumentata con il tempo, fino a raggiungere un rapporto del 75\% dei dati totali trasferiti per i video in diretta e del 98\% per i video \textit{on-demand}.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -619,7 +619,7 @@ Per i nostri test abbiamo utilizzato una combinazione di tecnologie open source
|
||||
|
||||
Docker è una piattaforma open source che semplifica la creazione, la distribuzione e l'esecuzione di applicazioni in contenitori. I contenitori Docker sono degli ambienti isolati che simulano un sistema operativo completo, come le macchine virtuali, consentendo di eseguire applicazioni in modo consistente su qualsiasi ambiente.
|
||||
|
||||
La differeneza tra docker e una macchina virtuale è che i container Docker condividono il kernel del sistema operativo host, riducendo l'overhead e migliorando le prestazioni, senza dover ricorrere ad un `Hypervisor' per la virtualizzazione.
|
||||
La differeneza tra docker e una macchina virtuale è che i container Docker condividono il kernel del sistema operativo host, riducendo l'overhead e migliorando le prestazioni, senza dover ricorrere ad un \footnote{Hypervisor: Software che consente di eseguire più sistemi operativi su singolo hardware.}\textit{Hypervisor} per la virtualizzazione.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -631,9 +631,9 @@ In se Docker è composto da 4 componenti principali:
|
||||
\begin{itemize}
|
||||
\item \textbf{Docker Engine}: Il core del sistema, responsabile della creazione e gestione dei container nonché il pricesso demone eseguito sulla macchina host. Fornisce l'accesso a tutte le funzionalità e i
|
||||
servizi messi a disposizione da Docker. Mette a disposizione un insieme di comandi per la gestione dei container, delle immagini e dei volumi.
|
||||
\item \textbf{Docker Client}: Interfaccia da riga di comando e `API' per interagire con Docker Engine.
|
||||
\item \textbf{Docker Image}: Un `template' di sola lettura che contiene e definisce i parametri di una applicazione da eseguire in un container a runtime. Le immagini vengono create e organizzate per livelli `stateless' e immutabil.
|
||||
\item \textbf{Docker Container}: Un'istanza in esecuzione di un'immagine Docker. Un container è un ambiente isolato che esegue un'applicazione specifica e include tutto il necessario per eseguire l'applicazione, come il codice, le librerie, le variabili d'ambiente e le dipendenze. Il `filesystem' del container è l'ultimo livello che viene aggiunto al quale vi è possibile accedere sia in lettura che in scrittura. I contenitori, inoltre, possono essere associati a dei volumi per la persistenza dei dati, i quali fornisono un metodo semplice e immediato per condivuidere dati tra i container e l'host.\\La comunicazione tra container avviene tramite la creazione di `network' o reti separate che vengono connesse ai singoli container, abilitando così una sorta di LAN interna tra un insieme di container. Per far, invece, comunicare i container con il mondo esterno bisogna invece utilizzare i `port mapping' tra una porta della macchina host e una porta del container.
|
||||
\item \textbf{Docker Client}: Interfaccia da riga di comando e \footnote{API: sinonimo di Application Programming Interface.} \textit{API} per interagire con Docker Engine.
|
||||
\item \textbf{Docker Image}: Un \textit{template} di sola lettura che contiene e definisce i parametri di una applicazione da eseguire in un container a runtime. Le immagini vengono create e organizzate per livelli \textit{stateless} e immutabil.
|
||||
\item \textbf{Docker Container}: Un'istanza in esecuzione di un'immagine Docker. Un container è un ambiente isolato che esegue un'applicazione specifica e include tutto il necessario per eseguire l'applicazione, come il codice, le librerie, le variabili d'ambiente e le dipendenze. Il \textit{filesystem} del container è l'ultimo livello che viene aggiunto al quale vi è possibile accedere sia in lettura che in scrittura. I contenitori, inoltre, possono essere associati a dei volumi per la persistenza dei dati, i quali fornisono un metodo semplice e immediato per condivuidere dati tra i container e l'host.\\La comunicazione tra container avviene tramite la creazione di \textit{network} o reti separate che vengono connesse ai singoli container, abilitando così una sorta di LAN interna tra un insieme di container. Per far, invece, comunicare i container con il mondo esterno bisogna invece utilizzare i `port mapping' tra una porta della macchina host e una porta del container.
|
||||
\end{itemize}
|
||||
|
||||
\begin{figure}[H]
|
||||
@@ -642,11 +642,11 @@ In se Docker è composto da 4 componenti principali:
|
||||
\caption{Docker Overview.}
|
||||
\end{figure}
|
||||
|
||||
Approfondendo il discordo del `networking', Docker mette a disposizione varti tipi di `network' per la comunicazione tra container, i 3 principali sono:
|
||||
Approfondendo il discorso del networking, Docker mette a disposizione varti tipi di reti per la comunicazione tra container, i 3 principali sono:
|
||||
\begin{itemize}
|
||||
\item \textbf{Bridge}: È il `network' di default che viene creato quando si installa Docker. I container connessi a questo `network' possono comunicare tra loro e con il host, ma non possono comunicare con i container in altri `network'.
|
||||
\item \textbf{Host}: I container connessi a questo `network' condividono la rete dell'host, quindi non hanno bisogno di fare il `port mapping' per comunicare con il mondo esterno.
|
||||
\item \textbf{None}: I container connessi a questo `network' non hanno accesso alla rete, quindi non possono comunicare con altri container o con l'esterno.
|
||||
\item \textbf{Bridge}: È la rete di default che viene creata quando si installa Docker. I container connessi a questa rete possono comunicare tra loro e con il host, ma non possono comunicare con i container in altre reti.
|
||||
\item \textbf{Host}: I container connessi a questa rete, condividono la rete dell'host, quindi non hanno bisogno di fare \textit{port mapping} per comunicare con il mondo esterno.
|
||||
\item \textbf{None}: I container connessi a questa rete non hanno accesso ad acluna rete, quindi non possono comunicare con altri container o con l'esterno.
|
||||
\end{itemize}
|
||||
|
||||
\begin{figure}[H]
|
||||
@@ -666,7 +666,7 @@ Telegraf è un agente di raccolta di metriche open source sviluppato da InfluxDa
|
||||
\caption{Architettura Telegraf.}
|
||||
\end{figure}
|
||||
|
||||
Scritto in `Go', Telegraf è dodato di oltre 300 plugin di input, trasformazione e output di dati, che consentono di raccogliere metriche da una vasta gamma di sorgenti. Per sua natura, funziona come un pipeline di dati che può essere instradata attraverso diversi plugin per elaborare e aggregare le informazioni prima di raggiungere l'output finale.
|
||||
Scritto in \textit{Go}, Telegraf è dodato di oltre 300 plugin di input, trasformazione e output di dati, che consentono di raccogliere metriche da una vasta gamma di sorgenti. Per sua natura, funziona come un pipeline di dati che può essere instradata attraverso diversi plugin per elaborare e aggregare le informazioni prima di raggiungere l'output finale.
|
||||
|
||||
Alcuni componenti principali di Telegraf includono:
|
||||
\begin{itemize}
|
||||
@@ -677,33 +677,33 @@ Alcuni componenti principali di Telegraf includono:
|
||||
\item \textbf{Aggregator Plugins}: Aggregano le metriche raccolte per ridurre il volume dei dati.
|
||||
\end{itemize}
|
||||
|
||||
La configurazione di Telegraf è definita da un file di configurazione `TOML' che definisce i plugin di input, processore e output da utilizzare, insieme a eventuali parametri aggiuntivi necessari per la raccolta e l'elaborazione delle metriche.
|
||||
La configurazione di Telegraf è definita da un file di configurazione \textit{TOML} che definisce i plugin di input, processore e output da utilizzare, insieme a eventuali parametri aggiuntivi necessari per la raccolta e l'elaborazione delle metriche.
|
||||
|
||||
Viene spesso utilizzato affianco ad un database di tipo `time-series' come InfluxDB per l'archiviazione e la visualizzazione delle metriche raccolte, ma può essere integrato con una vasta gamma di sistemi di monitoraggio e analisi dei dati.\\
|
||||
Una metrica `time-series' è una serie di dati indicizzati in sequenza rispetto al tempo. Un esempio è una sequenza di osservazioni o rilevazioni registrate allo scorrere del tempo. Vi sono due macrocategorie di time series:
|
||||
Viene spesso utilizzato affianco ad un database di tipo \textit{time-series} come InfluxDB per l'archiviazione e la visualizzazione delle metriche raccolte, ma può essere integrato con una vasta gamma di sistemi di monitoraggio e analisi dei dati.\\
|
||||
Una metrica \textit{time-series} è una serie di dati indicizzati in sequenza rispetto al tempo. Un esempio è una sequenza di osservazioni o rilevazioni registrate allo scorrere del tempo. Vi sono due macrocategorie di \textit{time-series}:
|
||||
\begin{itemize}
|
||||
\item \textbf{univariate time series}: le osservazioni sono monodimensionali, ovvero: viene registrato un solo valore numerico allo scorrere del tempo.
|
||||
\item \textbf{multivariate time series}: le osservazioni sono multidimensionali, ovvero, si registrano più valori numerici per un singolo istante di tempo.
|
||||
\end{itemize}
|
||||
Tipicamente, un `time-series' viene rappresentato con una struttura dati che registri un timestamp, che può essere di qualche tipo specifico per date, oppure un interocontenente uno `Unix timestamp'; oltre a questo contiene dati addizionali, che nella versione più semplice possono essere un unico valore numerico, ovvero l’osservazione registrata allo scorrere del tempo.
|
||||
Tipicamente, vengono viene rappresentate con una struttura dati che registri un timestamp, che può essere di qualche tipo specifico per date, oppure un intero, contenente uno \textit{Unix timestamp}; oltre a questo contiene dati addizionali, che nella versione più semplice possono essere un unico valore numerico, ovvero l’osservazione registrata allo scorrere del tempo.
|
||||
\cite{githubGitHubInfluxdatatelegraf} \cite{noauthor_telegraf_nodate} \cite{aiknowTimeSeries}
|
||||
|
||||
\subsection{MongoDB}
|
||||
|
||||
MongoDB è un database `NoSQL' open source, orientato ai documenti, sviluppato da MongoDB Inc. È progettato per essere flessibile, scalabile e ad alte prestazioni, consentendo di memorizzare e interrogare dati in modo efficiente.
|
||||
MongoDB è un database \textit{NoSQL} open source, orientato ai documenti, sviluppato da MongoDB Inc. È progettato per essere flessibile, scalabile e ad alte prestazioni, consentendo di memorizzare e interrogare dati in modo efficiente.
|
||||
Combina la capacità di scalare orizzontalmente con funzionalità come indici secondari, query per intervallo, ordinamento, aggregazioni e indici geospaziali.
|
||||
|
||||
Un database orientato ai documenti sostituisce il concetto di “riga” con un modello più flessibile, il “documento”. Grazie alla possibilità di includere documenti incorporati e array, l’approccio orientato ai documenti permette di rappresentare relazioni gerarchiche complesse all'interno di un singolo record.
|
||||
Un database orientato ai documenti sostituisce il concetto di `riga' con un modello più flessibile, il `documento'. Grazie alla possibilità di includere documenti incorporati e array, l’approccio orientato ai documenti permette di rappresentare relazioni gerarchiche complesse all'interno di un singolo record.
|
||||
Non ci sono schemi predefiniti: le chiavi e i valori di un documento non hanno tipi o dimensioni fisse. L'assenza di uno schema rigido rende più semplice aggiungere o rimuovere campi secondo necessità. In generale, questo accelera lo sviluppo, permettendo agli sviluppatori di iterare rapidamente e sperimentare con facilità rendendo possibile testare diversi modelli di dati e scegliere quello più adatto alle proprie esigenze.
|
||||
|
||||
MongoDB è progettato per essere un database generi co, quindi, oltre alle operazioni di interimento, lettura, aggiornamento e eliminazione dei dati (`CRUD'), offre alcune funzionalità uniche in più, tra cui:
|
||||
MongoDB è progettato per essere un database generi co, quindi, oltre alle operazioni di interimento, lettura, aggiornamento e eliminazione dei dati (\textit{CRUD}), offre alcune funzionalità uniche in più, tra cui:
|
||||
\begin{itemize}
|
||||
\item \textbf{Indicizzazioni}: MongoDB supporta indici di diversi tipi, tra cui indici singoli, composti, geospaziali e testuali. Gli indici possono essere creati per qualsiasi campo all'interno di un documento, consentendo di ottimizzare le query per le prestazioni.
|
||||
\item \textbf{Aggregazioni}: MongoDB offre un'ampia gamma di operazioni di aggregazione, come `group', `match', `project' e `sort', che consentono di eseguire query complesse e analisi dei dati direttamente nel database.
|
||||
\item \textbf{Collezioni speciali}: MongoDB supporta collezioni speciali come le collezioni di `time-series' e le collezioni `time-to-live', che semplificano la gestione di dati temporali e di dati che devono essere eliminati dopo un certo periodo di tempo come ad esempio le sessioni utente.
|
||||
\item \textbf{Indicizzazioni}: Indici di diversi tipi, tra cui indici singoli, composti, geospaziali e testuali. Gli indici possono essere creati per qualsiasi campo all'interno di un documento, consentendo di ottimizzare le query per le prestazioni.
|
||||
\item \textbf{Aggregazioni}: Un'ampia gamma di operazioni di aggregazione, come \textit{group}, \textit{match}, \textit{project} e \textit{sort}, che consentono di eseguire query complesse e analisi dei dati direttamente nel database.
|
||||
\item \textbf{Collezioni speciali}: Collezioni speciali come le collezioni\textit{time-series} e le collezioni \textit{time-to-live}, che semplificano la gestione di dati temporali e di dati che devono essere eliminati dopo un certo periodo di tempo come ad esempio le sessioni utente.
|
||||
\end{itemize}
|
||||
|
||||
MongoDB memorizza i record di dati come documenti (nello specifigo documenti `BSON', ovvero una rappresentazione binaria di documenti in formato `JSON'), che sono raggruppati in collezioni. Un database contiene una o più collezioni di documenti..
|
||||
MongoDB memorizza i record di dati come documenti (nello specifigo documenti \textit{BSON}, ovvero una rappresentazione binaria di documenti in formato \textit{JSON}), che sono raggruppati in collezioni. Un database contiene una o più collezioni di documenti.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -711,9 +711,9 @@ MongoDB memorizza i record di dati come documenti (nello specifigo documenti `BS
|
||||
\caption{Documento JSON.}
|
||||
\end{figure}
|
||||
|
||||
`JSON', JavaScript Object Notation, è un formato di scambio dati testuale, basato su una sintassi di oggetti JavaScript. È comunemente utilizzato per trasmettere dati strutturati su una rete, come ad esempio tra un server e un client web. Un documento `JSON', invece, è una collezione di campi e valori organizzata in un formato strutturato.
|
||||
\textit{JSON}, o JavaScript Object Notation, è un formato di scambio dati testuale, basato su una sintassi di oggetti JavaScript. È comunemente utilizzato per trasmettere dati strutturati su una rete, come ad esempio tra un server e un client web. Un \textit{documento JSON}, invece, è una collezione di campi e valori organizzata in un formato strutturato.
|
||||
|
||||
MongoDB Query Language, o `MQL', è il linguaggio di query utilizzato per interagire con un database MongoDB. MQL è simile a SQL, ma è progettato per lavorare con documenti JSON e collezioni di documenti, piuttosto che con tabelle e righe. Consente agli utenti di recuperare documenti che corrispondono a criteri specifici, eseguire aggregazioni, apportare aggiornamenti ai documenti ed effettuare cancellazioni di documenti. La sintassi di MQL è progettata per essere semplice e intuitiva. Permette agli utenti di specificare condizioni utilizzando operatori come \$eq (uguale), \$ne (diverso), \$gt (maggiore di), \$lt (minore di) e molti altri. È possibile anche utilizzare operatori `bitwise' come \$and, \$or e \$not per creare query complesse.
|
||||
MongoDB Query Language, o \textit{MQL}, è il linguaggio di query utilizzato per interagire con un database MongoDB. MQL è simile a SQL, ma è progettato per lavorare con documenti JSON e collezioni di documenti, piuttosto che con tabelle e righe. Consente agli utenti di recuperare documenti che corrispondono a criteri specifici, eseguire aggregazioni, apportare aggiornamenti ai documenti ed effettuare cancellazioni di documenti. La sintassi di MQL è progettata per essere semplice e intuitiva. Permette agli utenti di specificare condizioni utilizzando operatori come \$eq (uguale), \$ne (diverso), \$gt (maggiore di), \$lt (minore di) e molti altri. È possibile anche utilizzare operatori `bitwise' come \$and, \$or e \$not per creare query complesse.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -721,21 +721,15 @@ MongoDB Query Language, o `MQL', è il linguaggio di query utilizzato per intera
|
||||
\caption{MongoDB Aggregation Pipeline.}
|
||||
\end{figure}
|
||||
|
||||
Infine, il MongoDB Query Language Aggregation Framework, è un set di processi che trasforma i dati in strutture che possono essere utilizzate per l'analisi. L'aggregazione si basa su un concetto di `pipeline', in cui i documenti vengono passati attraverso una serie di fasi di trasformazione. Ogni fase della pipeline esegue un'operazione specifica sui documenti, come filtering, proiezione, ordinamento, raggruppamento e altro ancora. Le fasi della pipeline, possono essere quindi concatenate per creare query più complesse.\cite{10.5555/2544030} \cite{mongodbDocumentsMongoDB} \cite{knowiBestIntroduction}
|
||||
Infine, il MongoDB Query Language Aggregation Framework, è un set di processi che trasforma i dati in strutture che possono essere utilizzate per l'analisi. L'aggregazione si basa su un concetto di \textit{pipeline}, in cui i documenti vengono passati attraverso una serie di fasi di trasformazione. Ogni fase della pipeline esegue un'operazione specifica sui documenti, come filtering, proiezione, ordinamento, raggruppamento e altro ancora. Le fasi della pipeline, possono essere quindi concatenate per creare query più complesse.\cite{10.5555/2544030} \cite{mongodbDocumentsMongoDB} \cite{knowiBestIntroduction}
|
||||
|
||||
\subsection{Python}
|
||||
|
||||
Python è un linguaggio di programmazione ad alto livello, interpretato, orientato agli oggetti e con semantica dinamica. È progettato per essere facile da leggere e scrivere, con una sintassi pulita e chiara che favorisce la leggibilità del codice. Python è noto per la sua facilità d'uso e la sua versatilità, che lo rendono adatto a una vasta gamma di applicazioni, dallo sviluppo web alla data science, all'automazione dei processi.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=300pt]{images/python-logo-master-v3-TM.png}
|
||||
\caption{Python Logo.}
|
||||
\end{figure}
|
||||
Essendo un linguaggio interpretato, Python non richiede una fase di compilazione, ma viene eseguito direttamente da un \textit{interpreter}. Questo lo rende particolarmente adatto per lo sviluppo rapido di applicazioni e per l'iterazione veloce durante lo sviluppo. Python è anche noto per la sua vasta libreria standard, che fornisce un'ampia gamma di moduli e pacchetti pronti all'uso per svolgere una varietà di compiti comuni e per auesto viene utilizzato spesso per fare `data science'.\cite{10.5555/1593511}
|
||||
|
||||
Essendo un linguaggio interpretato, Python non richiede una fase di compilazione, ma viene eseguito direttamente da un `interpreter'. Questo lo rende particolarmente adatto per lo sviluppo rapido di applicazioni e per l'iterazione veloce durante lo sviluppo. Python è anche noto per la sua vasta libreria standard, che fornisce un'ampia gamma di moduli e pacchetti pronti all'uso per svolgere una varietà di compiti comuni e per auesto viene utilizzato spesso per fare `data science'.\cite{10.5555/1593511}
|
||||
|
||||
L'indentazione è parte fontamentale in quanto, a differenza di altri linguaggi di programmazione dove l'indentazione è solo una convenzione, in Python è obbligatoria e definisce la struttura del codice. Questo rende il codice più leggibile e coerente, ma richiede anche attenzione per mantenere la corretta struttura del codice.
|
||||
L'indentazione è parte fontamentale in quanto, a differenza di altri linguaggi di programmazione dove l'indentazione è solo una convenzione, in Python è obbligatoria e definisce la struttura del codice. Questo rende il codice più leggibile e coerente, ma richiede anche attenzione per mantenere una corretta struttura del codice.
|
||||
|
||||
\break
|
||||
|
||||
@@ -778,7 +772,7 @@ Selenium è un framework open-source ampiamente utilizzato per l'automazione dei
|
||||
|
||||
Uno degli aspetti chiave di Selenium è la sua capacità di funzionare con diversi browser, garantendo la compatibilità cross-browser e permettendo l'esecuzione di test in ambienti differenti.
|
||||
|
||||
Supporta diversi browser popolari, tra cui Google Chrome, Mozilla Firefox, Microsoft Edge, Safari e Opera. Ogni browser è gestito tramite implementazioni specifiche di `WebDriver', che fungono da ponte tra Selenium e il browser.
|
||||
Supporta diversi browser popolari, tra cui Google Chrome, Mozilla Firefox, Microsoft Edge, Safari e Opera. Ogni browser è gestito tramite implementazioni specifiche di \textit{WebDriver}, che fungono da ponte tra Selenium e il browser.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -790,7 +784,7 @@ Utilizzando i WebDriver, sviluppatori e tester possono scrivere script di automa
|
||||
|
||||
Una volta costruiti i casi di test, i dati devono essere comunicati al driver del browser in qualche modo. In Selenium, questo avviene utilizzando il `JSON Wire Protocol' con HTTP come gestore della comunicazione.
|
||||
|
||||
Poiché la comunicazione avviene in un'infrastruttura client-server, nel mondo di Selenium WebDriver questo sistema è noto come `request-response' o `command-response'.
|
||||
Poiché la comunicazione avviene in un'infrastruttura client-server, nel mondo di Selenium WebDriver questo sistema è noto come \textit{request-response} o \textit{command-response}.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -798,11 +792,11 @@ Poiché la comunicazione avviene in un'infrastruttura client-server, nel mondo d
|
||||
\caption{JSON Wire Protocol.}
|
||||
\end{figure}
|
||||
|
||||
Il funzionamento dei WebDriver può essere riassunto come:
|
||||
Il funzionamento dei WebDriver può essere riassunto in alcuni passaggi chiave:
|
||||
|
||||
\begin{itemize}
|
||||
\item Un tester scrive uno script di test automatizzato destinato a un driver di browser specifico.
|
||||
\item Quando viene premuto il pulsante “Esegui”, lo script viene convertito in formato API con dati in JSON.
|
||||
\item Quando viene premuto il pulsante `Esegui', lo script viene convertito in formato API con dati in JSON.
|
||||
\item I dati vengono trasferiti al driver del browser utilizzando il JSON Wire Protocol su una rete HTTP come API RESTful.
|
||||
\item Il driver del browser riceve i dati e, se la validazione ha successo, comunica le azioni al browser tramite HTTP.
|
||||
\item Se la validazione fallisce, gli errori vengono restituiti al client.
|
||||
@@ -813,11 +807,11 @@ Il funzionamento dei WebDriver può essere riassunto come:
|
||||
|
||||
Affinché il driver possa comunicare correttamente con il browser, è fondamentale che il browser stessso sia installato sul sistema, e che il sistema e il suo ambiente sia configurato correttamente, con tutti i prerequisiti necessari per l'esecuzione dei test.
|
||||
|
||||
Un altro componente messo a dispoizione da Selenium è, `Selenium Grid', che permette di eseguire test su più macchine e browser remoti contemporaneamente, riducendo i tempi di esecuzione e migliorando l'efficienza dei test, instradando i comandi inviati dal client alle istanze remote dei browser ed è composto da 2 componenti principali:
|
||||
Un altro componente messo a dispoizione da Selenium è, \textit{Selenium Grid}, che permette di eseguire test su più macchine e browser remoti contemporaneamente, riducendo i tempi di esecuzione e migliorando l'efficienza dei test, instradando i comandi inviati dal client alle istanze remote dei browser ed è composto da 2 componenti principali:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Hub}: Il server principale che funge da punto di ingresso per i test. Riceve i comandi dai client e li instrada alle istanze dei browser remote.
|
||||
\item \textbf{Node}: Le macchine remote che eseguono i test. Si connettono al `Hub' e ricevono i comandi per eseguire i test sui browser installati.
|
||||
\item \textbf{Node}: Le macchine remote che eseguono i test. Si connettono al \textit{Hub} e ricevono i comandi per eseguire i test sui browser installati.
|
||||
\end{itemize}
|
||||
|
||||
\begin{figure}[H]
|
||||
@@ -828,7 +822,7 @@ Un altro componente messo a dispoizione da Selenium è, `Selenium Grid', che per
|
||||
|
||||
Per fare tutto questo, Selenium mette a disposizione varie immagini Docker preconfigurate con tutto il necessario per eseguire i test, come il browser, il driver, l'hub, e le dipendenze necessarie, con anche diverse versioni legacy per testare la compatibilità con versioni obsolete.
|
||||
|
||||
In particolare, a noi interessa l'immagine `selenium/standalone-chrome', che contiene tutto il necessario per eseguire test su Chromium, incluso il browser stesso, il driver e il server Selenium, ed è stata usata come base per \textbf{creare una immagine Docker monolitica} per i nostri test, che include tutte le ulteriori dipendenze necessarie come:
|
||||
In particolare, a noi interessa l'immagine \textit{selenium/standalone-chrome}, che contiene tutto il necessario per eseguire test su Chromium, incluso il browser stesso, il driver e il server Selenium, ed è stata usata come base per \textbf{creare una immagine Docker monolitica} per i nostri test, che include tutte le ulteriori dipendenze necessarie come:
|
||||
\begin{itemize}
|
||||
\item \textbf{Python}: Per l'automazione.
|
||||
\item \textbf{Telegraf}: Per la raccolta ed invidio di tutte le metriche.
|
||||
@@ -843,7 +837,7 @@ WebRTC Internals Exporter è un'estensione per Chromium che consente di esportar
|
||||
L'uso di webrtc-internals con il processo di creazione/caricamento dei dump presenta alcune grosse limitazioni:
|
||||
|
||||
\begin{itemize}
|
||||
\item È necessario aprire la pagina `chrome://webrtc-internals' prima di avviare una sessione. Se la sessione è già in corso e si verificano problemi, non è possibile raccogliere metriche retroattivamente.
|
||||
\item È necessario aprire la pagina \textit{chrome://webrtc-internals} prima di avviare una sessione. Se la sessione è già in corso e si verificano problemi, non è possibile raccogliere metriche retroattivamente.
|
||||
\item La visualizzazione delle metriche è limitata nel tempo e non è possibile personalizzarle, filtrarle o creare query aggiuntive sui dati raccolti.
|
||||
\item L'uso di file dump può rendere difficile l'archiviazione e l'organizzazione dei dati dei test, oltre alla condivisione dei risultati. Inoltre, il caricamento di file dump di grandi dimensioni in altri strumenti di analisi, potrebbe richiedere molto tempo e memoria.
|
||||
\end{itemize}
|
||||
@@ -854,24 +848,24 @@ L'uso di webrtc-internals con il processo di creazione/caricamento dei dump pres
|
||||
\caption{Grafici WebRTC Internals.}
|
||||
\end{figure}
|
||||
|
||||
WebRTC Internals Exporter risolve questi problemi abilitando l'esportazione delle metriche verso un servizio chiamato Prometheus PushGateway.
|
||||
WebRTC Internals Exporter risolve questi problemi abilitando l'esportazione delle metriche verso un servizio chiamato \textit{Prometheus PushGateway}.
|
||||
Prometheus PushGateway è un servizio progettato per permettere a lavori effimeri e batch di esporre le proprie metriche a Prometheus. Poiché questi processi potrebbero non esistere abbastanza a lungo da essere interrogati direttamente, possono invece inviare le loro metriche al PushGateway, garantendo così la raccolta dei dati.
|
||||
|
||||
Tecnicamente l'estensione funziona in questo modo: viene precaricato un codice JavaScript che sovrascrive la classe globale `RTCPeerConnection'.
|
||||
Tecnicamente l'estensione funziona in questo modo: viene precaricato un codice JavaScript che sovrascrive la classe globale \textit{RTCPeerConnection}.
|
||||
|
||||
La nuova classe assegna un ID casuale a tutti gli oggetti peer connection creati e li memorizza all'interno dell'oggetto `webrtcInternalExporter'. L'utente può abilitare l'estensione per la scheda attualmente aperta facendo clic sull'icona dell'estensione e attivando la relativa checkbox.
|
||||
La nuova classe assegna un ID casuale a tutti gli oggetti peer connection creati e li memorizza all'interno dell'oggetto \textit{webrtcInternalExporter}. L'utente può abilitare l'estensione per la scheda attualmente aperta facendo clic sull'icona dell'estensione e attivando la relativa checkbox.
|
||||
|
||||
Dopo l'attivazione, lo script di override inizierà a chiamare periodicamente il metodo `getStats' sugli oggetti peer connection creati. Tutte le metriche selezionate verranno inviate allo script in background, che le inoltrerà al servizio PushGateway configurato.
|
||||
Dopo l'attivazione, lo script di override inizierà a chiamare periodicamente il metodo \textit{getStats} sugli oggetti creati. Tutte le metriche selezionate verranno inviate allo script in background, che le inoltrerà al servizio PushGateway configurato.
|
||||
|
||||
Il metodo `getStats' è un metodo standardizzato definito nell'API WebRTC che consente di ottenere le statistiche relative a una connessione peer-to-peer.\cite{WebRTCDebugging}
|
||||
Il metodo \textit{getStats} è un metodo standardizzato definito nell'API WebRTC che consente di ottenere le statistiche relative a una connessione peer-to-peer.\cite{WebRTCDebugging}
|
||||
|
||||
\
|
||||
|
||||
Questo progetto fa uso di una \textbf{versione altamente modificata} di WebRTC Internals Exporter, per adattarsi alle nostre esigenze di test e automazione. In particolare, abbiamo modificato le funzionalità:
|
||||
Questo progetto fa uso di una \footnote{Disponibile qui: \url{https://gitea.kobim.cloud/kobim/peertube-collector/src/branch/main/webrtc-internals-exporter}} \textbf{versione altamente modificata} di WebRTC Internals Exporter, per adattarsi alle nostre esigenze di test e automazione. In particolare, abbiamo modificato le funzionalità:
|
||||
|
||||
\begin{itemize}
|
||||
\item Abilitare l'esportazione delle metriche WebRTC verso un `endpoint' HTTP RESTful al posto di Prometheus PushGateway, con una formattazione dei dati personalizzata, ma sempre basata su JSON.
|
||||
\item Aggiunta di metriche esportate aggiuntive rispetto a quelle di base fornite da `getStats'.
|
||||
\item Abilitare l'esportazione delle metriche WebRTC verso un \textit{endpoint HTTP RESTful} al posto di Prometheus PushGateway, con una formattazione dei dati personalizzata, ma sempre basata su JSON.
|
||||
\item Aggiunta di metriche esportate aggiuntive rispetto a quelle di base fornite da \textit{getStats}.
|
||||
\item Abilitazione automatica dell'estensione all'avvio del browser, senza intervento manuale.
|
||||
\item Supporto alla configurazione tramite variabili d'ambiente per semplificare l'integrazione con il nostro sistema di test.
|
||||
\end{itemize}
|
||||
@@ -882,7 +876,7 @@ Hetzner Cloud è un servizio di cloud computing offerto da Hetzner Online GmbH,
|
||||
|
||||
Sulla base di quello che è stato fatto da PeerTube, abbiamo deciso di utilizzare Hetzner Cloud per distribuire i nostri test su macchine virtuali in diverse regioni geografiche, in quanto, gli script per l'automazione dei test sono l'unica parte fornitaci da PeerTube nell'articolo originale. Anche qua abbiamo utilizzato delle versioni altamente modificate per adattarle alle nostre esigenze.
|
||||
|
||||
Gli script fanno utilizzo della CLI, `Command-line interface', di Hetzner Cloud, che consente di gestire le risorse cloud direttamente dalla riga di comando, e sono formati da 2 parti principali: uno script per la creazione delle macchine virtuali e uno script per l'avvio dei test.
|
||||
Gli script fanno utilizzo della \footnote{CLI: sinonimo di Command-line interface} \textit{CLI}, di Hetzner Cloud, che consente di gestire le risorse cloud direttamente dalla riga di comando, e sono formati da 2 parti principali: uno script per la creazione delle macchine virtuali e uno script per l'avvio dei test.
|
||||
|
||||
Rispetto a quelli originali, li abbiamo modificati per far utilizzo delle varibili d'ambiente per la configurazione del nostro sistema di test, e per sostituire Selenium Grid, con l'immagine Docker monolitica standalone che abbiamo creato.\cite{githubGitHubHetznercloudcli} \cite{framagitFramasoftPeerTube}
|
||||
|
||||
@@ -890,7 +884,7 @@ Rispetto a quelli originali, li abbiamo modificati per far utilizzo delle varibi
|
||||
|
||||
Finora abbiamo descritto le tecnologie utilizzate alla base per creare il nostro sistema di test, senza però piegare effettivamente come queste vengono integrate e utilizzate insieme per creare un sistema di test automatizzato.
|
||||
|
||||
Introduciamo quindi l'ultimo pezzo necessario per far funzionare il tutto, ovvero il \textbf{`collector'}, un'applicazione Python che si occupa di fare scraping delle metriche di PeerTube, di raccogliere le metriche WebRTC tramite l'estensione Chromium, e di inviare il tutto a Telegraf per l'elaborazione e l'invio al database.
|
||||
Introduciamo quindi l'ultimo pezzo necessario per far funzionare il tutto, ovvero il \textbf{\textit{collector}}, un'applicazione Python che si occupa di fare \footnote{Il data scraping è una tecnica in cui un programma informatico estrae dati da un output leggibile dall'uomo generato da un altro programma.} \textbf{scraping} delle metriche di PeerTube, di raccogliere le metriche WebRTC tramite l'estensione Chromium, e di inviare il tutto a Telegraf per l'elaborazione e l'invio al database.
|
||||
|
||||
TODO
|
||||
|
||||
|
Reference in New Issue
Block a user