feat: enhance test scenarios description and update statistics collected for PeerTube use cases
All checks were successful
Build LaTeX Document / build_latex (push) Successful in 3m8s
All checks were successful
Build LaTeX Document / build_latex (push) Successful in 3m8s
This commit is contained in:
2
.github/workflows/main.yml
vendored
2
.github/workflows/main.yml
vendored
@@ -20,7 +20,7 @@ jobs:
|
||||
- name: Install MiKTeX
|
||||
run: |
|
||||
curl -fsSL https://miktex.org/download/key | tee /usr/share/keyrings/miktex-keyring.asc > /dev/null
|
||||
echo "deb [signed-by=/usr/share/keyrings/miktex-keyring.asc] https://miktex.org/download/ubuntu noble universe" | sudo tee /etc/apt/sources.list.d/miktex.list
|
||||
echo "deb [signed-by=/usr/share/keyrings/miktex-keyring.asc] https://miktex.org/download/ubuntu jammy universe" | sudo tee /etc/apt/sources.list.d/miktex.list
|
||||
apt-get update
|
||||
apt-get dist-upgrade -y
|
||||
apt-get install miktex -y
|
||||
|
25
Tesi.tex
25
Tesi.tex
@@ -1020,6 +1020,11 @@ Nello specifico il \textit{collector} è composto da 3 parti principali:
|
||||
|
||||
Selenium e WebRTC Internals Exporter li abbiamo già descritti in precedenza, mentre il Python script è il cuore del sistema, che si occupa di coordinare le altre componenti, di avviare e fermare i test, di raccogliere i dati, aggregarli e di inviarli a Telegraf per l'invio al database.
|
||||
|
||||
L'intero progetto è disponibile qui:
|
||||
\begin{itemize}
|
||||
\item \url{https://gitea.kobim.cloud/kobim/peertube-collector}
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Difficoltà incontrate e soluzioni}
|
||||
|
||||
Durante la creazione del sistema, abbiamo incontrato diverse difficoltà, per lo più sistemistiche, che hanno richiesto soluzioni creative per superarle. Alcune delle principali sfide sono state:
|
||||
@@ -1091,7 +1096,7 @@ I passaggi presenti in figura \ref{fig:architettura-collector} possono essere ri
|
||||
\item \textbf{Avvio del test}: Viene caricata la pagina del video e tramite Selenium viene controllato che il video sia in riproduzione tramite il controllo dell'esistenza del bottone play.
|
||||
\item \textbf{Raccolta delle metriche WebRTC}: L'estensione per WebRTC inizia a raccogliere le metriche e ogni 2 secondi circa le invia allo script principale. Viene quindi di fatto instaurato un ciclo che viene usato dallo script come sorgente di clock per la raccolta delle altre metriche.
|
||||
\item \textbf{Raccolta delle metriche video di PeerTube}: Utilizzando BeautifulSoup, vengono trasformate e raccolte le metriche del player video di PeerTube, come la qualità del video, il buffering, quantità di dati trasferiti, la latenza, e altro ancora. Il tutto viee convertito in un formato JSON.
|
||||
\item \textbf{Invio delle metriche a Telegraf}: Le metriche raccolte, vengono inviate a Telegraf tramite una socket di sistema, per l'elaborazione e l'invio al database finale, nel nostro caso MongoDB. C'è un passaggio fondamentale però che Telegraf esegue, ed è quello di fare \textit{string-join} dei dati JSON, ovvero di `appiattire' e trasformare i dati in una stringa, per poi inviarli al database. Questo viene fatto in quanto Telegraf, utilizzando il plugin di input per il formato JSON, converte gli array \textbf{in singole metriche separate}, e non come un unico documento, perdendo quindi la struttura originale dei dati. In se qusto non è un problema, ma per la nostra analisi, è fondamentale mantenere la struttura originale dei dati per facilitarci il lavoro.
|
||||
\item \textbf{Invio delle metriche a Telegraf}: Le metriche raccolte, vengono inviate a Telegraf tramite una socket di sistema, per l'elaborazione e l'invio al database finale, nel nostro caso MongoDB. C'è un passaggio fondamentale però che Telegraf esegue, ed è quello di fare \textit{string-join} dei dati JSON, ovvero di `appiattire' e trasformare i dati in una stringa, per poi inviarli al database. Questo viene fatto in quanto Telegraf, utilizzando il plugin di input per il formato JSON, converte gli array \textbf{in singole metriche separate}, e non come un unico documento, perdendo quindi la struttura originale dei dati. In se qusto non è un problema, ma per la nostra analisi, è fondamentale mantenere la struttura originale dei dati per facilitarci il lavoro. Infine per ricavare i documenti interi, un ulteriore passaggio finale va effettuato nel database, in differita, per convertirli da stringhe ad oggetti JSON validi.
|
||||
\end{itemize}
|
||||
|
||||
Va inoltre evidenziata la scelta di utilizzare un solo script Python per coordinare il tutto, sia l'inizializzazione che raccolta delle metriche dalle pagine web e dalla estensione esterna, in quanto questo ha semplificato la gestione e soprattutto la creazione del sistema e permette come bonus di avere un unico punto di controllo per l'intero processo.
|
||||
@@ -1170,21 +1175,20 @@ Il diagramma finale dell'architettura del nostro sistema è il seguente:
|
||||
|
||||
\section{Casi d'uso e scenari di test riprodotti}
|
||||
|
||||
Abbiamo riprodotto i due principali scenari descritti nell'articolo di PeerTube:
|
||||
Come descritto in precedenza, abbiamo riprodotto due scenari di test principali dei 4 casi d'uso descritti nell'articolo di PeerTube per motivi di tempo e risorse. Questi sono:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Live streaming con impostazione Normal Latency}: Il setup standard di PeerTube
|
||||
\item \textbf{Live streaming con impostazione High Latency}: Una configurazione che privilegia l'efficienza P2P a scapito della latenza
|
||||
\item Live streaming con impostazione \textit{Normal Latency}: Il setup standard di PeerTube
|
||||
\item Live streaming con impostazione \textit{High Latency}: La configurazione che privilegia il P2P a scapito della latenza
|
||||
\end{itemize}
|
||||
|
||||
Per ciascuno scenario, abbiamo variato il numero di spettatori (10, 30, 50, 100) e misurato:
|
||||
Per ciascun scenario, abbiamo impostato il numero di spettatori/utenti a 5 (limite di Hetzner Cloud per account nuovi) e racolto le seguenti statistiche:
|
||||
|
||||
\begin{itemize}
|
||||
\item Percentuale di dati trasferiti via P2P vs. dal server
|
||||
\item Latenza media e picchi
|
||||
\item Utilizzo di CPU e memoria sui client
|
||||
\item Qualità dell'esperienza utente (buffering, interruzioni)
|
||||
\item Comportamento in condizioni di rete variabili
|
||||
\item Statistiche del player web (risoluzione, bitrate, buffering, latenza, ecc.)
|
||||
\item Statistiche WebRTC (peer connection, ICE candidates, ICE connection state, ecc.)
|
||||
\item Informazioni identificative dei singoli peer (url del video, ID sessione, ID peer)
|
||||
\item Timestamp di raccolta
|
||||
\end{itemize}
|
||||
|
||||
\chapter{Analisi dei dati e risultati}
|
||||
@@ -1197,7 +1201,6 @@ Per ciascuno scenario, abbiamo variato il numero di spettatori (10, 30, 50, 100)
|
||||
|
||||
\nocite{*}
|
||||
\printbibliography
|
||||
\sloppy
|
||||
\addcontentsline{toc}{chapter}{Bibliografia}
|
||||
|
||||
\end{document}
|
Submodule peertube/statnerd updated: 7b4b922923...19839cd520
Reference in New Issue
Block a user