Article supprimé le 31 janvier 2015 à la demande de la gendarmerie nationale.
Nous allons dans ce billet essayer d’optimiser le streaming d’un flux SD sur un réseau local (LAN de 100 Mbps) en utilisant le framework GStreamer.
Environnement des tests
Deux PC Ubuntu connectés sur un même switch (100 Mbps full-duplex).
- PC serveur: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz / 2 Go RAM
- PC client: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz / 1 Go RAM
GStreamer version 0.10.25.
Vidéo source: Big Buck Bunny 480p
Tests avec le codec X.264
Ligne de commande sur la machine générant le streaming (serveur):
serveur> gst-launch -v \ filesrc location= »../Vidéos/big_buck_bunny_480p_stereo.ogg » \ ! queue ! decodebin \ ! queue ! videoscale method=1 ! video/x-raw-yuv,width=854,height=480 \ ! queue ! videorate ! video/x-raw-yuv,framerate=\(fraction\)24/1 \ ! queue ! x264enc byte-stream=true bitrate=2000 bframes=4 ref=4 me=hex subme=4 weightb=true threads=0 \ ! queue ! rtph264pay \ ! queue ! udpsink port=5000 host=192.168.29.150 sync=false async=false
Ligne de commande sur la machine recevant le streaming (client):
client> gst-launch -v udpsrc caps= »application/x-rtp, media=\(string\)video, clock-rate=\(int\)90000, encoding-name=\(string\)H264, payload=\(int\)96″ port=5000 \
! queue ! rtph264depay \
! queue ! ffdec_h264 ! xvimagesink
Résultat:
Visuel: vidéo saccadé (environ 2 img/sec)
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=135 / %MEM=5
Resource client: %CPU=10 / %MEM=2
On ajoute un buffer juste avant le depay et le décodage (au niveau du client):
client> gst-launch -v udpsrc caps= »application/x-rtp, media=\(string\)video, clock-rate=\(int\)90000, encoding-name=\(string\)H264, payload=\(int\)96″ port=5000 \
! queue ! gstrtpjitterbuffer latency=3000 \
! queue ! rtph264depay \
! queue ! ffdec_h264 ! xvimagesink
Résultat:
Visuel: vidéo beaucoup plus fluide mais variation de la gigue (accéleration de la video par moment). On a par contre un décalage de 3 secondes, donc inutilisable pour des flux lives.
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=140 / %MEM=6
Resource client: %CPU=14 / %MEM=2
On modifie ensuite les paramètres d’encodage X.264 (au niveau du serveur):
serveur> gst-launch -v –gst-debug-level=2 \
filesrc location= »../Vidéos/big_buck_bunny_480p_stereo.ogg » \
! queue ! decodebin \
! queue ! videoscale method=1 ! video/x-raw-yuv,width=720,height=480 \
! queue ! videorate ! video/x-raw-yuv,framerate=\(fraction\)24/1 \
! queue ! x264enc vbv-buf-capacity=3000 byte-stream=true bitrate=900 subme=4 ref=2 bframes=1 b-pyramid=true weightb=true \
! queue ! rtph264pay \
! queue ! udpsink port=5000 host=192.168.29.150 sync=false async=false
Résultat:
Visuel: Presque plus de sacade ni de variation de gigue. On a par contre un décalage de 3 secondes, donc inutilisable pour des flux lives.
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=120 / %MEM=4
Resource client: %CPU=10 / %MEM=2
Curl-Loader est un logiciel libre, écrit en langage C (le meilleur langage pour développer des applications réseaux), permettant de simuler sur votre serveur WEB ou FTP un grand nombre de connexions simultanées. Nous allons dans ce billet voir comment installer, configurer et tester ce logiciel dans un environnement GNU/Linux (Ubuntu 9.10 dans mon cas).
Installation de Curl-Loader
Comme il n’est pas encore (des volontaires ?) disponible dans les dêpots officiels, il va falloir compiler Curl-Loader à la main. Avant d’aller plus loin, on installe des pré-requis système:
[shell]
sudo aptitude install build-essential openssl libssl-dev
[/shell]
On commence par récupérer la dernière version disponible (0.51 au moment de l’écriture de ce billet):
[shell]
wget http://downloads.sourceforge.net/project/curl-loader/curl-loader/curl-loader-0.51/curl-loader-0.51.tar.gz?use_mirror=sunet
[/shell]
On décompresse et compile le tout:
[shell]
tar zxvf curl-loader-0.51.tar.gz
cd curl-loader-0.51
make optimize=1
[/shell]
On finalise l’installation avec:
[shell]
sudo make install
[/shell]
Configuration de Curl-Loader
Tout est centralisé dans un fichier de configuration. Quelques exemples de fichiers de conf sont fournis avec les sources dans le répertoire ./conf-exemples/.
Le plus simple est de partir du fichier ./conf-exemples/bulk.conf:
[shell]
cp ./conf-exemples/bulk.conf ~/curlloader.conf
cd ~
[/shell]
On édite le fichier pour l’adapter à son besoin (documentation exhaustive disponible sur le site officiel) :
[shell]
vi curlloader.conf
[/shell]
[shell]
########### GENERAL SECTION ################################
BATCH_NAME= bulk
CLIENTS_NUM_MAX=200
CLIENTS_RAMPUP_INC=5
INTERFACE=eth0
NETMASK=24
IP_ADDR_MIN= 192.168.29.148
IP_ADDR_MAX= 192.168.29.148
IP_SHARED_NUM=1
CYCLES_NUM= 100
URLS_NUM= 1
########### URL SECTION ####################################
URL=http://www.monserveurweb.com/
URL_SHORT_NAME="MonServeurWeb"
REQUEST_TYPE=GET
TIMER_URL_COMPLETION = 5000
TIMER_AFTER_URL_SLEEP = 500
[/shell]
Utilisation de Curl-Loader
Attention à ne lancer Curl_Loader que vers un serveur qui vous appartient.
Dans le cas contraire, cela peut être considéré comme une attaque par dénie de service !
Il ne reste plus qu’a lancer Curl-Loader avec ce fichier de configuration:
[shell]
sudo curl-loader -f ~/curlloader.conf
[/shell]
Que va faire l’exécution de Curl-Loader avec notre fichier de configuration ?
On commence un cycle en envoyant sur le réseau 5 (CLIENTS_RAMPUP_INC) requêtes simultanées vers le serveur Web d’URL http://www.monserveurweb.com/(URL), puis 1 seconde plus tard, 5 requêtes de plus et ainsi de suite jusqu’à 200 (CLIENTS_NUM_MAX) requêtes simultanées. A la fin de ce cycle, on continu jusqu’à attendre le 100em cycle (CYCLES_NUM).
A la fin du test on a les informations suivantes qui s’affichent:
[shell]
Test total duration was 54 seconds and CAPS average 231:
H/F Req:24665,1xx:0,2xx:12332,3xx:12333,4xx:0,5xx:0,Err:0,T-Err:1,D:1ms,D-2xx:3ms,Ti:1343807B/s,To:56181B/s
H/F/S Req:0,1xx:0,2xx:0,3xx:0,4xx:0,5xx:0,Err:0,T-Err:0,D:0ms,D-2xx:0ms,Ti:0B/s,To:0B/s
Exited. For details look in the files:
– bulk.log for errors and traces;
– bulk.txt for loading statistics;
– bulk.ctx for virtual client based statistics.
– bulk.ops for operational statistics.
[/shell]
Pour la le lecture des rapports, voici un petit mémento:
- CAPS=call attempts per seconds;
- run-time in seconds;
- requests num;
- 1xx success num;
- 2xx success num;
- 3xx redirects num;
- client 4xx errors num;
- server 5xx errors num;
- other errors num, like resolving, tcp-connect, server closing or empty responses number (Err);
- url completion time expiration errors (T-Err);
- average application server Delay (msec), estimated as the time between HTTP request and HTTP response without taking into the account network latency (RTT) (D);
- average application server Delay for 2xx (success) HTTP-responses, as above, but only for 2xx responses. The motivation for that is that 3xx redirections and 5xx server errors/rejects may not necessarily provide a true indication of a testing server working functionality (D-2xx);
- throughput in, batch average, Bytes/sec (T-In);
- throughput out, batch average, Bytes/sec (T-Out);
Firefox 3.7 sous Ubuntu (dépôts)
Après Firefox 3.6.5, c’est la version 3.7 qui prendra le relai des navigateurs Web de Mozilla. Selon PC INpact, la principale nouveauté de cette version est l’intégration de la technologie d’Electrolysis:
» Electrolysis a pour objectif principal de permettre à Firefox l’utilisation de tous les cœurs disponibles dans la machine. La grande majorité des machines vendues aujourd’hui dispose d’au moins deux cœurs d’exécution, sinon quatre. Le navigateur ne peut en utiliser qu’un seul. Ainsi, lors de l’affichage de certaines pages, la charge peut grimper à 100 % et déclencher la pleine vitesse du ventilateur, en particulier dans un ordinateur portable. »
Il est déjà possible de tester cette nouvelle version (qui est actuellement en développement) sous son système d’exploitation GNU/Linux Ubuntu en suivant la procédure suivante.
On commence par ajouter le dépôts PPA officiel (les « daily builds » de Mozilla):
[shell]
sudo add-apt-repository ppa:ubuntu-mozilla-daily
sudo aptitude update
[/shell]
Ensuite on installe Firefox 3.7 (qui peut cohabiter avec des versions antérieures) avec la commande:
[shell]
sudo aptitude install firefox-3.7
[/shell]
Il ne reste plus qu’a lancer le navigateur en allant dans le menu « Applications » (Internet/Minefield 3.7 Web Browser) ou en ouvrant un terminal et en lancant la commande:
[shell]
firefox-3.7
[/shell]
Et voilà le travail !
MRTG, un tutoriel simple et rapide
Si vous suivez ce blog, vous devez sûrement connaitre Cacti, l’outil permettant de générer des graphes visualisation via une interface HTML/PHP. La solution, bien que simple à mettre en oeuvre nécessite quelques manipulations. Nous allons voir dans ce billet une autre solution beaucoup moins lourde et simple à mettre en oeuvre: MRTG. Nous nous limiterons à la génération de graphes représentant la bande passante des interfaces réseau mais l’on peut bien sûr « grapher » toutes les mesures récupérables via SNMP. La machine qui hébergera notre MRTG est sous Unbuntu 9.10 (mais la procédure est globalement la mêmes sur les autres distribution GNU/Linux).
Mes « marques ta-pages » de la semaine
- Wake on LAN depuis un PC Linux
- Configurer un serveur OpenVPN en 60 secondes grâce au script de Nigi Fabio
- Le guide ultime du crontab
- 10 extensions pour Chromium (sans big brother) et Google Chrome (avec big brother)
- Sauvergarder son compte Gmail avec Offlineimap
- OpenShot video, enfin un éditeur vidéo digne de ce nom libre sous Linux ?
- Des effets visuels CSS3 pour présenter vos images
- La version 5.2 de NMap vient de sortir avec pleins de nouveautés !
- Trisquel, une distribution GNU/Linux 100% libre !
- Supprimer le double tirets de WordPress
- Un bien belle page sur le mode vidéo de HTML5
NTop est un outil libre (licence GPL) de supervision réseau permettant d’afficher en temps réel les informations collectées dans une interface Web. Pour effectuer cette collecte, NTop se base sur la librairie libpcap (du projet TCPDump) pour capturer les flux transitant sur les interfaces réseau de la machine ou est installé le logiciel. Les dernières versions de NTop permettent également de collecter des informations venant de machines distantes grâce aux protocoles SNMP et Netflow/IPfix. C’est sur ce dernier point que nous allons nous focaliser dans ce billet.
Mes « marques ta-pages » de la semaine
Voici une méthode simple rapide et efficace (enfin plus rapide à mettre en place que NRPE) pour surveiller l’espace disque disponible de ses machines Linux/BSD/Windows à partir de Nagios en utilisant le protocole SNMP.
Les pré-requis sont les suivants:
- avoir un Nagios correctement installé
- la machine à surveiller doit héberger un serveur SNMP dont la configuration permette au serveur Nagios de lire les informations (l’accès read-only v1/v2 de SNMP est suffisant)
- suivre la suite de ce billet 😉
Configuration de la machine à surveiller
Après avoir installé et configuré son serveur SNMP, il faut ajouter la ligne suivante au fichier de configuration snmpd.conf (la localisation de ce dernier est os dépendant):
[shell]
disk / 100000
[/shell]
PS: le deuxième paramètre permet de fixer le seuil en dessous duquel une alerte SNMP est remontée. Il n’est pas très important pour nous car c’est Nagios qui va générer cette alerte avec nos propres valeurs.
On doit bien sûr relancer le service snmpd pour lire la configuration, par exemple:
[shell]
/etc/init.d/snmpd restart
[/shell]
Configuration du serveur Nagios
La première chose à faire est de vérifier que l’on arrive bien à récupérer les informations SNMP sur la machine à surveiller (d’adresse IP 192.168.0.200 dans notre exemple). Pour cela on peut utiliser la commande suivante:
[shell]
snmpget -v 1 -c public 192.168.0.200 .1.3.6.1.4.1.2021.9.1.9.1
UCD-SNMP-MIB::dskPercent.1 = INTEGER: 32
[/shell]
La commande a réussi. On a bien récupéré la valeur 32 par SNMP. Donc On a 32% d’espace disque occupé sur le disque de la machine 192.168.0.200.
On configure Nagios de la manière suivante, on édite le fichier commands.cfg:
[shell]
#################
# check_snmp_disk
#################
# Check free disk space using SNMP (add the "disk 1000000" line to the snmpd.conf)
define command{
command_name check_snmp_disk
command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o .1.3.6.1.4.1.2021.9.1.9.1 -C $ARG1$ -w $ARG2$ -c $ARG3$ -u "% used"
}
[/shell]
Puis on configure le service pour la machine à surveiller (dans un autre fichier comme par exemple services.cfg):
[shell]
define service{
use generic-service
host_name Ma_Machine_192.168.0.200
service_description DISK SPACE
check_command check_snmp_disk!public!90!95
}
[/shell]
La fonction check_snmp_disk prend 3 paramètres:
- le nom de la communauté SNMP (public)
- le seuil au dessus duquel un warning est généré par Nagios (90%)
- le seuil au dessus duquel un error est généré par Nagios (95%)
Il ne reste plus qu’a relancer Nagios pour prendre en compte la configuration !
Pour soutenir la « Quadrature du net »
Vous connaissez tous la « Quadrature du net », cette association qui lute contre les lois menaçant nos libertés individuelles dans le monde numérique (notamment Hadopi, LOPPSI…). Comme toute assoc, elle a des frais que seule votre générosité peut combler…
La « Quadrature du net » lance donc une campagne de dons (via Paypal ou par chèque). Si vous êtes sensible à leurs actions, je vous recommande de donner quelques-uns de vos chers €uros…
A votre bon coeur…
Vive le libre, vive la liberté !