[script] comparer efficatité navigateurs

Ce qui ne concerne ni le forum ni des problèmes
Avatar de l’utilisateur
kozaki
Chu Ko Nu
Messages : 422
Inscription : mer. 13 sept. 2006, 22:49
Localisation : London > . < Paris
Contact :

[script] comparer efficatité navigateurs

Message par kozaki »

Propal pour --j'ai jamais fait donc excusez les défauts et la simplicité :

- comparer les navs en fonction de critères réels en rapport avec son matos et ses usages
- trouver/conseiller un nav efficace sur une machine Y pour un usage X
par ex. sur configs minimalistes/portables. Et sur plus costaudes, choisir le navi pour quand tu veux surfer en mode "Lucky-Luke", "Bip-bip" (coyote inside) ou poids-plume.
- remplacer ces « j'ay l'impression / jejurerai / trouve Chromium + lourd que Dillo » par des chiffres carrés
- mesurer les heures gagnées (hmmm vraiment ?) chaque semaine avec mes/tes/ses extensions et chtis réglages userland/système ;}
- se PTDR à chaque fois qu'un gars vante les scores de son nav au binchemarques / s'en sert pour le choisir
- trouver le navi le plus KISS. On est sur Arch bo*del
benchmark a écrit :please close other browsers, tabs and make sure your screen stays awake the whole time during the test.
C'fait quelques années que j'surfe et utilise un ordi un peu pas comme ça. Sûr les benchmarks testent quelque-chose, mais vu les conditions de test, je doute que ça mesure l'efficacité du navi comme je l'utilise. OK, hors mode diaporama (et encore, j'arrête pas la sync de fichiers ou compil). Mais comment mesurer l'efficacité d'un nav au quotidien ? Au papier et à la console mon pépère.

Spoiler :
Scores bainchemarques Browsermark, Jetstream et Octane 2 (higher is better)
Image
...Temps en seconde pour charger 10 pages (et un email, soyons fous)
Image

C'fou non ?

Scenarios :
  • LÉGER - Lancer le nav, afficher 10 pages et afficher le premier email/message.
  • POWA - 40 pages, afficher son webmail et afficher la 40è ou vice-versa.
  • puis... vas y lâche toi !-)
Mesure:

A - Lancé À froid cache vidé
  • TEMPS
    LEGER --> pour avoir la main sur le nav; afficher la 1ère page; la dernière et puis ouvrir un premier email
    "temps pour afficher une première page": Selon mes tests seuls les navigateurs efficaces sur cette config y parviennent; les plus lourds y arrivent simplement pas, même en cliquant quelques fois sur le 1er onglet pendant qu'il charge les suivants.
    POWA --> pour afficher le webmail et la dernière page (ndlr souvent la dernière ouverte la session préc.)
    je tente d'afficher le webmail ASAP avant que les 29 autres pages soient chargées. Dans mes tests, les seuls navs qui le permettent a) sont cap' d'afficher rapidement les pages, b) mettent pas ce système à genoux *et* c) ont une interface assez efficace pour que j'y arrive. Je note le temps mis pour afficher le premier (webmail ou dernière page), puis le second. C'est ma façon de tester la vitesse réelle du nav, pour l'utilisateur.
  • RÉPONDANT: nav et système après ouverture de la dernière page, pour bûtiner entre quelques onglets, ouvrir un message, scroller. Moto, voiture, bus ou super-tanker :mrgreen:
  • RESSOURCES: Système avant le test. RAM tapée par le navi (pendant le load, dernière page affichée, après bûtinage). CPU load average (premier triplet) une fois les pages chargées. IO wait: comme le l.a.
B - À chaud: pareil sauf le cache.
On jarte le paramètre disque (temps d'accès touça) pour mesurer les seules perfs du navi --et du buffer-cache OS.

C - VIa le gestionnaire de session :
je me tâtais pour çuila alros que ne devrais pas : c'est ça le scénario courant, eh pépère :) Puis les résultats sont surprenants selon l'efficacité du gestionnaire de session du navigateur (par ex: charger les pages 3 par 3 ou "ne charger les onglets qu'à la demande") !

--> Moyenne de 3 lancements.
Avec :
a) tous les réglages par défaut
b) le nav customisé (ses petites extensions et réglages favoris ;} )
c) l'OS customisé selon machine, goûts (et compétences)

Les URLs sont chargées, via 2 scripts Bash. ENvoient une page chaque 2 sec, et puis les mesures de charge dans un fichier de log $test-$host-$kernel-arch-$navi[-restart].txt

Code : Tout sélectionner

#!/usr/bin/env sh
                                                                                 
# Variables
#BROWSER=palemoon          # or set it on the fly
#file="urls-10"
#file="urls-40"
#USER=whoami

# -----[ part 1 ]------

info="$(pwd)/$file-$(hostname)-$(uname -rms)-$BROWSER-$(date +%Y%m%d_%H%M).txt"

# 1. Utime & RAM before; launch the browser:
echo -e "1) Before\n$(uptime)\n$(free -m)\n"   > "$info"
$BROWSER

# -----[ part 2 ]------

# 2. Load the URLs, waiting 2 sec between each for sanity
#
# Mozilla
for line in $(cat $file); do "$BROWSER" -new-tab "$line" & 2>/dev/null; sleep 2; done
#
# Google Chrome/ium & Lightfirefox
#for line in $(cat $file); do "$BROWSER" --new-tab "$line" & 2>/dev/null; sleep 2; done

# Midori
#for line in $(cat $file); do "$BROWSER" -e open-new-pages-in "$line" & 2>/dev/null; sleep 2; done
#
# Xombrero (requires 'socket' on in the conf file)
#for line in $(cat $file); do $BROWSER -n "$line" & 2>/dev/null; sleep 2; done

# 2.1: CPU, la / wa & RAM usage while loading ('echo -e' below removed for readability)
sleep 5;                                                                        
$(top -b -n 1 | head -3)  >> "$info"

sleep 30;
top -b -n 1 | head -5 && free -m >> "$info"

sleep 60;
top -b -n1 -U "$USER" && free -m   >> "$info"

# 2.4 (urls-40): ~three minutes after launching the $BROWSER:
sleep 60;
top -b -n1 -U "$USER" && free -m  >> "$info"

# 2.5 (urls-40): ~five minutes after launching the $BROWSER:
sleep 120;
top -b -n1 -U "$USER" && free -m   >> "$info"
                                                                                 
# 3. Close the $BROWSER & RAM after
pkill -15 $BROWSER
sleep 10;
free -m  >> "$info"

# If the script does not work for some reason just do it on the cmd line         

# Thanks @ hamsolo474
Vos scénarios, idées d'amélioration et critiques constructives sont très bienvindues ^^
Par ex. j'mapperçois qu'y a peu de chances de mesurer les « fuites mémoire » là. Pour ça faudrait "voir" au bout d'un moment.
Notez que le test fait partie d'un projet pour comparer l'efficacité de softs et réglages cross-architectures.

EDIT 1: correction (merci Bobo) et MÀJ du script et du pourquoi.
EDIT 2: Spoiler, détail des mesures faites pour y arriver et question.
Dernière modification par kozaki le mar. 26 janv. 2016, 02:29, modifié 4 fois.
~ Configs ~ PGP Key: 1C2A554EFF0157D9
« Demande un conseil à ton ennemi et fais le contraire (proverbe juif)
SVP intéressé par tout retour d'exp. sur Arch ARM en général, et sur portable (CrOS) en particulier.
bobo
Elfe
Messages : 593
Inscription : mar. 08 avr. 2014, 22:47

Re: [script] comparer efficatité navigateurs

Message par bobo »

Cool ce script !! Ça a l'air pas mal du tout comme benchmarks :bravo:

Il y a pas mal de lignes à commenter/décommenter en fonction du navigateur testé. On sent que la variable $BROWSER a été un essai pour s'affranchir de cette contrainte. Pour ça j'ai quelques suggestions :
– utiliser des arguments pour définir $file et $BROWSER sans changement de code dans le script

Code : Tout sélectionner

USAGE : cescript <benchmark> [browser]
– faire des cas selon $BROWSER pour ouvrir les nouvelles pages => voir http://bash.cyberciti.biz/guide/The_case_statement
– si aucun argument n'est détecté, utiliser le $BROWSER par défaut, une piste pour la détection :

Code : Tout sélectionner

$ grep -i exec $(find $HOME -iname $(xdg-settings get default-web-browser))
Exec=/usr/lib/firefox/firefox %u
$ grep -i exec $(find $HOME -iname $(xdg-settings get default-web-browser)) | sed -e "s:^Exec=::" -e "s/ .*//"
/usr/lib/firefox/firefox
Ensuite quelque pistes d'amélioration :
– stocker les benchmarks dans des fichiers (listes des sites, date, navigateur, version navigateur, temps, emprunte mémoire, nombre de tests…), avec un "grep -v" bien senti on pourrait relancer le même bench si toutes les données à part la liste des sites sont précédé d'un caractère donné :

Code : Tout sélectionner

$ echo "seule_ligne_voulue" > toto.test
$ echo "# 1er cas " >> toto.test
$ echo "   # 2eme cas " >> toto.test
$ echo -e "\t# 3eme cas " >> toto.test
$ grep -v "^\s*#" toto.test
seule_ligne_voulue
– faciliter le reboot en fin de benchmark (l'idéal serait d'automatiser complètement benchmark -> reboot -> login auto -> benchmark et lancer le tout avec une liste de navigateurs à tester, mais c'est chaud compte-tenu des disparités de méthodes de login)
dwm — BÉPO — vim — “more is less !”
bobo
Elfe
Messages : 593
Inscription : mar. 08 avr. 2014, 22:47

Re: [script] comparer efficatité navigateurs

Message par bobo »

Comment tu fais pour obtenir le temps de run du navigateur ?

Sinon il semble qu'il y ait une typo dans ton code (le -n de head)

Code : Tout sélectionner

top -b -n 1 | head -n 5
dwm — BÉPO — vim — “more is less !”
Avatar de l’utilisateur
kozaki
Chu Ko Nu
Messages : 422
Inscription : mer. 13 sept. 2006, 22:49
Localisation : London > . < Paris
Contact :

Re: [script] comparer efficatité navigateurs

Message par kozaki »

– faciliter le reboot en fin de benchmark (l'idéal serait d'automatiser complètement benchmark -> reboot -> login auto -> benchmark et lancer le tout avec une liste de navigateurs à tester, mais c'est chaud compte-tenu des disparités de méthodes de login)
That's it ! :copain:
Et garder les mains libres. Puis vider le buffer/cache système et nav plutôt que reboot OS; c'est ce que je fais (pour Chromium et Midori via un rm -f ~/.cache/.../Cache/* - pas vu où le vider facile via les navis, puis c'est plus rapide :D )
Je matte tes tuyaux demain bobo.
Comment tu fais pour obtenir le temps de run du navigateur ?
Pas sûr de piger précisément. Sinon avec un chrono dans la paluche gauche et le clavier sous la droite (pas assez souple pour mettre les pieds)
~ Configs ~ PGP Key: 1C2A554EFF0157D9
« Demande un conseil à ton ennemi et fais le contraire (proverbe juif)
SVP intéressé par tout retour d'exp. sur Arch ARM en général, et sur portable (CrOS) en particulier.
bobo
Elfe
Messages : 593
Inscription : mar. 08 avr. 2014, 22:47

Re: [script] comparer efficatité navigateurs

Message par bobo »

Je viens juste de tomber sur la commande time du paquet time, ça devrait être mieux que le chrono ;)

Code : Tout sélectionner

$ /usr/bin/time -f "\n%E elapsed\n%M memory" sleep 2
0:02.00 elapsed
1728 memory
Ça permet de récupérer :
– le temps écoulé dans l'exécution de la commande
– le max de mémoire utilisée
http://linux.about.com/od/commands/a/Ex ... d-Time.htm

C'est utilisable pour ajouter des lignes à un fichier existant :

Code : Tout sélectionner

$ echo "test" > ~/toto
$ /usr/bin/time -f "# %E elapsed\n# %M memory" -a -o ~/toto sleep 2
$ cat ~/toto
test
# 0:02.00 elapsed
# 1808 memory
Il est possible de faire une parser qui :
– crée le fichier en recopiant la liste les URLs à ouvrir
– ajoute $BROWSER
– lance avec time la commande avec le cas pour ouvrir le navigateur et toutes les URLS, et ferme le le navigateur
– ajoute le temps passé et l'emprunte mémoire automatiquement

Dans ce cas il faut couper ton script en deux : le « parser » et la « boucle avec cas »
dwm — BÉPO — vim — “more is less !”
Avatar de l’utilisateur
benjarobin
Maître du Kyudo
Messages : 17185
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [script] comparer efficatité navigateurs

Message par benjarobin »

Mesurer ainsi ne te donnera ni le temps d'ouverture du navigateur avant qu'il soit utilisable, ni le temps de chargement d'une page Web. Alors oui tu peux par contre mesurer la quantité de mémoire vive consommée, mais ce sera sans aucune interaction avec le navigateur, autant dire que cela ne vaut rien : La consommation de mémoire peut changer en fonction de si tu as vu la page (cliquer sur l'onglet) et quelle portion de la page tu as vu (scroller : défiler verticalement la page)
Zsh | KDE | PC fixe : core i7, carte nvidia
Titre d'un sujet : [Thème] Sujet (état) / Règles du forum
bobo
Elfe
Messages : 593
Inscription : mar. 08 avr. 2014, 22:47

Re: [script] comparer efficatité navigateurs

Message par bobo »

benjarobin a écrit :Mesurer ainsi ne te donnera ni le temps d'ouverture du navigateur avant qu'il soit utilisable, ni le temps de chargement d'une page Web.
Même si tu utilises time au lancement du script boucle ?

Code : Tout sélectionner

case $BROWSER
  firefox)
    for line in $(cat $file); do "$BROWSER" -new-tab "$line" & 2>/dev/null; sleep 2; done
  ;;
  midori)
  …
esac
dwm — BÉPO — vim — “more is less !”
Avatar de l’utilisateur
benjarobin
Maître du Kyudo
Messages : 17185
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [script] comparer efficatité navigateurs

Message par benjarobin »

time mesure le temps d’exécution d'un processus (ouverture + exécution + fermeture). Comment veux tu que time soit au courant que la page a été chargé ou que les menus du navigateur soient opérationnels.
Zsh | KDE | PC fixe : core i7, carte nvidia
Titre d'un sujet : [Thème] Sujet (état) / Règles du forum
bobo
Elfe
Messages : 593
Inscription : mar. 08 avr. 2014, 22:47

Re: [script] comparer efficatité navigateurs

Message par bobo »

benjarobin a écrit :Comment veux tu que time soit au courant que la page a été chargé ou que les menus du navigateur soient opérationnels.
Je vois bien où mon approche pèche : je ne vois pas de moyen simple de vérifier que les pages ont été chargées dans le navigateur. Ça peut se régler sans chrono, avec un message d'information (ou toute autre interaction humaine) pour définir la fin du processus.

Je viens de faire un test avec pour squelette la boucle de kozaki et un message zenity en fin de script pour valider que le navigateur est prêt :

Code : Tout sélectionner

$ cat ~/test.bash
#!/bin/bash

BROWSER=$(basename $1)
file=$2
flag=0

case $BROWSER in
	"firefox")
		for line in $(cat $file); do "$BROWSER" -new-tab "$line" & 2>/dev/null; sleep 2; done
	;;
	*) flag=1 ;;
esac

if [ $flag == 0 ]; then
	zenity --info --text "Valider quand le navigateur est prêt"
else
	zenity --warning --text "Le navigateur n'a pas été trouvé"
fi
En exécutant ce script via la commande time, avec un message box pour valider le lancement du navigateur ça fonctionne très bien :

Code : Tout sélectionner

$ /usr/bin/time -f "# %E elapsed\n# %M memory" ./test.bash /usr/lib/firefox/firefox list_urls 
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
# 0:07.67 elapsed
# 48188 memory
Ça me paraît fonctionnel pour le temps. Le décompte mémoire est plus délicat : je viens de me rendre compte qu'en cas de navigateur non-détecté on avait quasi autant de mémoire consommée, sans doute que la mémoire décomptée l'ai pour le processus père uniquement, et pas pour les processus fils.
dwm — BÉPO — vim — “more is less !”
Avatar de l’utilisateur
kozaki
Chu Ko Nu
Messages : 422
Inscription : mer. 13 sept. 2006, 22:49
Localisation : London > . < Paris
Contact :

Re: [script] comparer efficatité navigateurs

Message par kozaki »

Bobo tes encouragements et idées sont motivants là ^o^
bobo a écrit :- en faisant des cas selon $BROWSER

ÀMA tu vas dans la bonne direction en cherchant comment automatiser plus le test. Réduire le temps passé à tester, c'est déterminant pour la faisabilité du projet de test. Pour moi (j'ai quand même 2-3 autres activités et tester (N navs * 3 passes * 4 tests)*default/nav-custom/os-custom*nombre-d-os est un poil chaud ;) et pour le diffuser. Puis en cherchant les causes du succès des binchemarques, on note vite que le rôle de l'utilisateur consommateur final c'est cliquer un rro bouton.
bobo a écrit :– stocker les benchmarks dans des fichiers (listes des sites, date, navigateur, version navigateur, temps, emprunte mémoire, nombre de tests…), avec un "grep -v" bien senti on pourrait relancer le même bench si toutes les données à part la liste des sites sont précédé d'un caractère donné :

Tout à fait Thierry ;) d'ailleurs pouvoir se référer aux logs détaillés est carrément nécessaire, rien que pour MÀJ le tableau simplifié en cas de besoin ! Je l'ai implémente ce WE (et édité le script du 1er post) :

Code : Tout sélectionner

info="$(pwd)/$file-$(hostname)-$(uname -rms)-$BROWSER-$(date +%Y%m%d_%H%M).txt"
Exemple joint ci-dessous.
– faciliter le reboot en fin de benchmark (l'idéal serait d'automatiser complètement benchmark -> reboot -> login auto -> benchmark et lancer le tout avec une liste de navigateurs à tester, mais c'est chaud compte-tenu des disparités de méthodes de login)
Automatiser je suis pour; complètement vu l'objectif et comme benjarobin l'a pointé, ça va être un poil chô :D
Après quelques heures (couf couf) passées à tester, je pense que la full automatisation est l'apannage des benchmarks synthétiques. Y-a 2 manips que je fais pour mesurer la réactivité du navi pendant un load et une fois les 10 ou 40 pages ouvertes. 'Confirment généralement les chiffres du LA et du wait IO en général, mais aussi les affinent. Hé c'est que mon avis. Une solution plus automatisée et ptet moins précise est sans doute possible. @bobo je peux ouvrir un git, ça t'intéresse ?

Pour tester un autre nav comme j'ai dit hier

Code : Tout sélectionner

echo 3 > /proc/sys/vm/drop_cache # vide le buffer/cache Linux
rm -rf $HOME/.cache/$BROWSER/Cache/*
# Sur système avec très peu de RAM ou OS codé avec des mouffles faut aussi vider le swap:
swapoff -a && swapon -a 
permet de faire N cold start en évitant de rebooter.

urls-40-gwenael-Linux 4.0.7-2-ARCH x86_64-chromium-20160119_1855.txt sur le petit Intel dual-core :

Code : Tout sélectionner

-----------------------------[ Cold start ]---------------------------------------- 
1) Before                                                                        
 18:55:36 up 2 days, 16:19,  4 users,  load average: 0,07, 0,60, 0,80            
              total        used        free      shared  buff/cache   available  
Mem:           1995        *145*       1758          17          91        1731  
Swap:          2047           0        2047                                      
                                                                                 
2.1 Loading                                                                      
top - 18:57:35 up 2 days, 16:21,  4 users,  *load average: 14,78*, 4,88, 2,26         
Tasks: 193 total,  13 running, 176 sleeping,   4 stopped,   0 zombie             
%Cpu(s): 14,8 us,  2,0 sy,  0,2 ni, 82,3 id,  *0,7 wa*,  0,0 hi,  0,0 si,  0,0 st  
                                                                                 
2.2 One minute                                                                   
top - 18:58:06 up 2 days, 16:22,  4 users,  *load average: 12,96*, 5,40, 2,52         
Tasks: 160 total,  10 running, 146 sleeping,   4 stopped,   0 zombie             
%Cpu(s): 14,8 us,  2,0 sy,  0,2 ni, 82,3 id,  0,7 wa,  0,0 hi,  0,0 si,  0,0 st  
                                                                                 
  PID USER      PR  NI    VIRT    RES  %CPU %MEM     TIME+ S COMMAND             
 8817 kozaki    20   0  951,0m 161,2m  30,6  8,1   0:41.58 S chromium            
 9203 kozaki    20   0  925,4m 140,9m  22,4  7,1   0:11.75 R chromium            
 9737 kozaki    20   0  901,3m 127,5m  16,3  6,4   0:11.25 R chromium            
10020 kozaki    20   0  889,7m 114,5m  16,3  5,7   0:07.61 R chromium            
 9123 kozaki    20   0  869,1m  99,1m  12,2  5,0   0:03.83 R chromium        

              total        used        free      shared  buff/cache   available  
Mem:           1995         965         664          61         365         821  
Swap:          2047           0        2047

2.3 Two minutes                                                                  
top - 18:59:06 up 2 days, 16:23,  4 users,  *load average: 11,17*, 6,32, 3,02      
Tasks: 160 total,   9 running, 147 sleeping,   4 stopped,   0 zombie             
%Cpu(s): 14,8 us,  2,1 sy,  0,2 ni, 82,3 id,  0,7 wa,  0,0 hi,  0,0 si,  0,0 st  
                                                                                 
  PID USER      PR  NI    VIRT    RES  %CPU %MEM     TIME+ S COMMAND             
 9683 kozaki    20   0  931,1m 129,5m  31,6  6,5   0:13.34 R chromium            
 8817 kozaki    20   0  941,0m 165,5m  26,3  8,3   0:58.74 R chromium            
 9043 kozaki    20   0  942,4m 157,3m  15,8  7,9   0:15.96 R chromium            
 9430 kozaki    20   0  974,8m 173,0m  15,8  8,7   0:20.24 R chromium            
 9518 kozaki    20   0  930,5m 160,4m  15,8  8,0   0:21.88 R chromium            
                                                                                 
              total        used        free      shared  buff/cache   available  
Mem:           1995        1232         357          83         405         532  
Swap:          2047           0        2047                                      
                                                                                 
2.4 Three minutes                                                                
top - 19:00:07 up 2 days, 16:24,  4 users, *load average: 6,96*, 6,15, 3,19       
Tasks: 161 total,   1 running, 156 sleeping,   4 stopped,   0 zombie             
%Cpu(s): 14,9 us,  2,1 sy,  0,2 ni, 82,3 id,  0,7 wa,  0,0 hi,  0,0 si,  0,0 st  
                                                                                 
  PID USER      PR  NI    VIRT    RES  %CPU %MEM     TIME+ S COMMAND             
 8881 kozaki    20   0  568,7m  66,7m  10,5  3,3   0:17.49 S chromium            
 9737 kozaki    20   0 1054,8m 213,3m  10,5 10,7   0:48.62 S chromium            
 9811 kozaki    20   0  927,2m 132,4m  10,5  6,6   0:23.36 S chromium            
11948 kozaki    20   0   40,2m   3,5m  10,5  0,2   0:00.06 R top                 
 8817 kozaki    20   0  948,2m 169,9m   5,3  8,5   1:16.06 S chromium            
                                                                                 
              total        used        free      shared  buff/cache   available  
Mem:           1995       *1370*        191          98         433         379  
Swap:          2047           0        2047                       
                                                                                 
2.5 Five minutes                                                                 
top - 19:02:07 up 2 days, 16:26,  4 users,  *load average: 1,16, 4,22*, 2,84       
Tasks: 155 total,   2 running, 149 sleeping,   4 stopped,   0 zombie             
%Cpu(s): 14,9 us,  2,1 sy,  0,2 ni, 82,2 id,  0,7 wa,  0,0 hi,  0,0 si,  0,0 st  
                                                                                 
  PID USER      PR  NI    VIRT    RES  %CPU %MEM     TIME+ S COMMAND             
 6182 kozaki    20   0   64,8m  17,5m  29,4  0,9   1:17.17 R vim                 
11970 kozaki    20   0   40,2m   3,7m  23,5  0,2   0:00.06 R top                 
  693 kozaki    20   0   17,7m   3,9m   0,0  0,2   0:00.00 T bash                
  694 kozaki    20   0    6,1m   0,8m   0,0  0,0   0:00.00 T cat                 
  734 kozaki    20   0   17,7m   3,9m   0,0  0,2   0:00.00 T bash                
                                                                                 
              total        used        free      shared  buff/cache   available  
Mem:           1995       *1324*        235          95         435         428  
Swap:          2047           0        2047
Un dernier 'free -m' permet de mesurer l'efficacité du système à rendre la RAM dispo pour d'autres tâches. Arch linux --default-- est juste parfait pour le job; Ubuntu c'est pas pareil (rien d'horrible hein) ;)

Projets d'améliorations :
Copier des pages en local (contre : temps, et supprime le gros des possibilités d'interaction)
Multi-tasking : insérer ce test navi dans une session un peu + large
Batch pour le lancer sous les Fenêtres :D

Si le script vous passionne (pas) que pensez-vous de prendre les pages les plus souvent visitées de son navi comme référence, pour coller à nos quotidiens/ réalité ?
~ Configs ~ PGP Key: 1C2A554EFF0157D9
« Demande un conseil à ton ennemi et fais le contraire (proverbe juif)
SVP intéressé par tout retour d'exp. sur Arch ARM en général, et sur portable (CrOS) en particulier.
Avatar de l’utilisateur
kozaki
Chu Ko Nu
Messages : 422
Inscription : mer. 13 sept. 2006, 22:49
Localisation : London > . < Paris
Contact :

Re: [script] comparer efficatité navigateurs

Message par kozaki »

Résultats partiels montrent que sur une petite machine c'est assez énorme !

En X = WebXPRT, en Y = Octane 2. La taille des boules = score Browsermark (+ haut = navi + performant)
Image

X = Browsermark, Y = Jetstream, et boules = Octane 2
Image

Le même avec projection Voronoi-Tessellation, j'espère que vous avez chopé les codes de coulours
Image

Ça c'était la moyenne des résultats de ces navs sur ces grands benchmarks.
L'usabilité réelle maintenant :

Le temps pour charger une 1ère page en démarrant à froid (j'aime peindre avec la queue du chat :D )
Image
En X le temps pour charger charger une 1ère page, en Y pour ouvrir un premier message Gmail (dans la 10è onglet Gmail). Taille de boule = conso RAM après 2-3'
Image

La même pour afficher la 40è page et afficher le webmail (40 urls)
Image

C'est bizarre, plus le navi rame pour afficher les pages, plus il tape fort sur le système. Un truc intéressant à mesurer pour tous ceusees qui ont un portable serait la conso électrique à scénario/action, temps et machine égaux !
~ Configs ~ PGP Key: 1C2A554EFF0157D9
« Demande un conseil à ton ennemi et fais le contraire (proverbe juif)
SVP intéressé par tout retour d'exp. sur Arch ARM en général, et sur portable (CrOS) en particulier.
bobo
Elfe
Messages : 593
Inscription : mar. 08 avr. 2014, 22:47

Re: [script] comparer efficatité navigateurs

Message par bobo »

J'avais commencé une réponse mais je me suis interrompu. Un git ce serait pas mal pour suivre l'évolution du code, et potentiellement contribuer/tester.

Si j'ai bien compris tu as comparé tes résultats avec des benchmarks standards et tracé des belles courbes. Les grands benchmarks sont en opposition à ton benchmark de chargement de page.

Pourrait-on avoir du détail sur les benchmarks ?
— WebXPRT
— Octane 2
— Browsermark
(ça pourrait être pas mal de savoir ce qui est mesuré…)

Sinon d'autres questions :
Et c'est quoi le logiciel que tu as utilisé pour les courbes ? C'est quoi le principe du graphique avec « la queue du chat » ?
dwm — BÉPO — vim — “more is less !”
Avatar de l’utilisateur
kozaki
Chu Ko Nu
Messages : 422
Inscription : mer. 13 sept. 2006, 22:49
Localisation : London > . < Paris
Contact :

Re: [script] comparer efficatité navigateurs

Message par kozaki »

(ça pourrait être pas mal de savoir ce qui est mesuré…)
Bin pourquoi, l'important est de savoir qui a le plus fermor.. permorf.. le plus rapide en un clic, nan ?
Pour casser du sucre sur les pauvres gusses qui utilisent encore d'autres navs que le mien arf! les pov! Tu vois ? :mrgreen:

OK voici quelques infos (en notant que je savais rien de précis sur les bainchemarques jusqu'il y a 15 jours). Eye! tu saurais en choisir =<5 représentatifs alias de référence ? Pendant que chaque test tourne... Oooops ! pas touche au système ! (ajoute NN beinchemarques x N navis x OSes x réglages/profils x N machines aux tests réalistes, y-a vite fait de s'appeler Maurice).
Classés par thème errr, selon mes compétences :

Meta-benchmarks
Dromaeo, outil de test universel des performances DOM, CSS, Javascript d'une traite ou séparément - par Mozilla. Ex. de résultats décortiqués
Peacekeeper, bainchemarque les perfs JavaScript, la compatibilité, le rendering et perfs WebGL HTML5, la vitesse de MÀJ DOM, les web worker threads (multi-threaded JavaScript) - par Futuremark, indépendant (d'où le nom ;) ; 2013.
EEMBC BrowsingBench, Test complete page load and render time, as well as browser subsystem performance. Résultats les plus proches de mes tests jusque là. Développé ; indépendant ?

Perfs Javascript
Octane, remplace la V8 Benchmark Suite. Measure [your hardware-browser] JavaScript performance for code found in large, real-world web applications, running on modern mobile and desktop browsers. Doc. Développé, par Chromium/Google.
Jetstream 1.1 test les perfs sur ~toutes les librairies et fonctionnalités javascript d'aujourd'hui ; détail. Développé, indépendant ?
Browsermark : 'core un mais qu'est-ce-qu'il teste de plus ?? Par Basemark (OS II, X, ES 3.1 sur terminaux mobiles), développé, indépendant ?
WebXPRT, bainchemarque les perfs sur surf, office en ligne, manipulation d'images et données en ligne sur PC et terminaux mobiles - Par PrincipledTechnologies et les auteurs de Ziff-Davis Media' Winstone et WebBench, ZD Labs, eTesting Labs, et VeriTest). FAQ. Développé ; indépendant ?
Speedometer: outil de benchmark javascript (suuuper long sur petites configs) - par les mêmes que Jetstream.
Sunspider. « Suite de test à prédominence Javascript conçue par WebKit pour mesurer les performances du nav en situ réelle ». Toujours été favorable à MSIE/Edge - Développé.

Perfs graphiques
OORTILINE, conçu pour évaluer les performances WEBGL et le respect de l'implémentation HTML 5. Développé; indy ?
CanvasMark (ex-Asteroïds), bainchemarque JavaScript qui teste les performances HTML5 en rendering Canvas 2D pour des opés courantes dans les jeux HTML5. 2013 (remplace Psychedelic Browsing à tomshardware.fr)
Impact HTML5, teste « how well HTML5 games perform in the browser. » (2D HTML5 Impact game engine)
KaizouMark, benchmarque les performances CSS3 du nav où on le lance. 2012, indépendant.
WebVizBench, bainchemarque le framerate HTML5 3D
Scirra WebGL, teste le rendu WebGL (sur petite config c'est même plus long là... sponsorisé par la justice ?)
Luic WebGL Performance Benchmark, mesure les performances graphiques HTML5 3D du navi-OS-machine (choisi pour remplacer la démo WebGL d'Airtight Interactive par l'équipe de test navigateurs à Tomshardware.fr). Développé, pas pigé comme le faire tourner à cette heure.
Si j'ai bien compris tu as comparé tes résultats avec des benchmarks standards et tracé des belles courbes. Les grands benchmarks sont en opposition à ton benchmark de chargement de page.
Belle synthèse.
Et aussi les navs par défaut les + efficaces sur une petite config.

Bin ya pas de secret ! Après moult essais frustrants (impression d'être trop demeuré et/ou pas assez en fonds pour pondre *un* graphique lisib') je me suis arrêté sur RAW.

Je précise que mon objectif est d'élargir mon horizon habituel et piger/apprendre : monitorer l'utilisation ressources, shell scripting, tester... ; navis, multi-threading/cores, x86 vs ARM ; et motivations des acteurs. Mon avis sur les bainchemarques (comme dit plus haut) est que ~tous leurs résultats sont drôlement biaisés par la méthode et le contexte de mesure. Au mieux un bench mesure l'efficacité (Javascript, DOM, CSS, 2D, 3D...) du système+navigateur+machine sur une maudite page. Nickel pour qui ouvre Fessebouc (point) :non: À priori l'optimisation réseau joue pas (sauf EEMBC p-ê.), je verrai bien après config DNS.

QUESTIONS :
- Quel autre scénario et mesures tu ferais pour comparer l'efficacité des navigateurs pour un usage concret (sur un matos donné au quotidien) ?
- Copier des pages en local ? (contre : temps, et supprime le gros des possibilités d'interaction)
- Multi-tasking càd. insérer ce scénario navi-centrique dans une session un peu + réaliste (en cours)
- Pour maximiser la portabilité (Batch pour le lancer sous les Fenêtres...)
~ Configs ~ PGP Key: 1C2A554EFF0157D9
« Demande un conseil à ton ennemi et fais le contraire (proverbe juif)
SVP intéressé par tout retour d'exp. sur Arch ARM en général, et sur portable (CrOS) en particulier.
bobo
Elfe
Messages : 593
Inscription : mar. 08 avr. 2014, 22:47

Re: [script] comparer efficatité navigateurs

Message par bobo »

kozaki a écrit : Meta-benchmarks

Perfs Javascript

Perfs graphiques
Rhoo le bourrin qui a fait le tour des benchmarks navigateurs. C'est possible que les gros navigateurs s'en tirent mieux sur ces benchs à cause d'une supondération du javascript couplé à une optimisation, ou du préchargement qui allourdit l'ouverture de page.
kozaki a écrit :Je précise que mon objectif est d'élargir mon horizon habituel et piger/apprendre : monitorer l'utilisation ressources, shell scripting, tester... ; navis, multi-threading/cores, x86 vs ARM ; et motivations des acteurs. Mon avis sur les bainchemarques (comme dit plus haut) est que ~tous leurs résultats sont drôlement biaisés par la méthode et le contexte de mesure. Au mieux un bench mesure l'efficacité (Javascript, DOM, CSS, 2D, 3D...) du système+navigateur+machine sur une maudite page. Nickel pour qui ouvre Fessebouc (point) :non: À priori l'optimisation réseau joue pas (sauf EEMBC p-ê.), je verrai bien après config DNS.
Je m'étais égaré en pleine lecture du man de la commande ps qui pourrait permettre de récupérer la conso mémoire et le temps CPU, peut-être d'autres choses. Je te conseillerais bien de regarder. Ça pourrait bien complémenter la mesure de temps ressenti avec /usr/bin/time sur le script « case&for ».
kozaki a écrit :QUESTIONS :
- Quel autre scénario et mesures tu ferais pour comparer l'efficacité des navigateurs pour un usage concret (sur un matos donné au quotidien) ?
- Copier des pages en local ? (contre : temps, et supprime le gros des possibilités d'interaction)
- Multi-tasking càd. insérer ce scénario navi-centrique dans une session un peu + réaliste (en cours)
- Pour maximiser la portabilité (Batch pour le lancer sous les Fenêtres...)
Je ne vois pas trop quoi ajouter… Ton idée de base me semble pas mal du tout : temps de chargement de pages utiles à l'utilisateur, et emprunte mémoire. Qu'entends-tu par « Batch pour le lancer sous les Fenêtres... » ?
dwm — BÉPO — vim — “more is less !”
Avatar de l’utilisateur
kozaki
Chu Ko Nu
Messages : 422
Inscription : mer. 13 sept. 2006, 22:49
Localisation : London > . < Paris
Contact :

Re: [script] comparer efficatité navigateurs

Message par kozaki »

bobo a écrit :Rhoo le bourrin qui a fait le tour des benchmarks navigateurs.
Vi, puis ça aide à répondre aux flemmes qui me demandent (!) " mais que fait tel biiinchemarque ?" plutôt qu'aller voir :non:

Benchmarks

Sur la grande question e̶x̶i̶s̶t̶e̶n̶c̶i̶e̶l̶l̶e̶ testosteronale : À qui servent les benchmarks ? la conclusion de ce gars met un point final :
The benchmarks don’t matter. The speed of the browsers in the benchmarks simply doesn't matter.
The benchmarks matter to the developers. Developers use benchmarks to discover and fine-tune places within their browsers that could use a bit of code cleanup and optimization to achieve the best performance. To a developer, having more compact code, or code that shaves off a millisecond here or there, is a good way [to evaluate how succesful was his job on this].
Tom Nelson. Un Exemple.
Un peu comme si les batteries de tests utilisées par les ingénieurs cyclo, moto GP ou F1 pour j̶u̶s̶t̶i̶f̶i̶e̶r̶ ̶l̶e̶u̶r̶s̶ ̶s̶a̶l̶a̶i̶r̶e̶s̶ étaient accessibles à tous et utilisées pour choisir sa prochaine bécane/twingo (ou pour glorifier sa paire de... heu ATI SLI achetée un bras par ex).
C'est en cherchant qu'on trouve :) Confirme ce que je pensais-mais-vaguement. Et surtout, la dèche en matière de tests permettant d'évaluer l'efficacité réelle des moult navis.

Du coup pour le choix des benchmarks à utiliser ?
Puisqu'utilisés comme étalon-or, on peut garder pour comparer, par exemple :
- 1 opérations de manipulation javascript -> lequel ?
- 1 HTML5 Canvas / WebGL (graphique) -> lequel ?
- 1 pour les designers -> Kaizoumark (CSS3);
- 1 généraliste -> webXPRT (javascript itou orienté manipulations sur sites Web 2.0 grand public) ou EEMBC Browsingbench (le seul qui reflète un poil le profiling en situ réelle pour l'instant).

Mesurer l'efficacité
bobo a écrit :Je m'étais égaré en pleine lecture du man de la commande ps qui pourrait permettre de récupérer la conso mémoire et le temps CPU, peut-être d'autres choses. Je te conseillerais bien de regarder. Ça pourrait bien complémenter la mesure de temps ressenti avec /usr/bin/time sur le script « case&for ».
Que trouve tu qu'il manque aux résultats fournis par 'free'. ps_mem est encore plus précis (mémoire privée et shared par ex)... et + chaud à implémenter.
Il faut mesurer la charge chiffrée en parallèle aux timings, oui. Le Load Average donne une putain de mesure de la charge que met une action/app sur la machine. "load" != CPU utilisation mais = le CPU queue length, plus utile pour audit perfs et capacity planning. Genre les outils d'analyse des cours financiers. Puis s'utilise / s'interprête pareil pour mesurer un workload simple / un multi-processus.
Et y-a aussi le IO wait, clé pour évaluer les possibles goulets d'étranglement.
bobo a écrit :
kozaki a écrit :QUESTIONS :
- Quel autre scénario et mesures tu ferais pour comparer l'efficacité des navigateurs pour un usage concret (sur un matos donné au quotidien) ?
- Copier des pages en local ? (contre : temps, et supprime le gros des possibilités d'interaction)
- Multi-tasking càd. insérer ce scénario navi-centrique dans une session un peu + réaliste (en cours)
- Pour maximiser la portabilité (Batch pour le lancer sous les Fenêtres...)
Je ne vois pas trop quoi ajouter… Ton idée de base me semble pas mal du tout : temps de chargement de pages utiles à l'utilisateur, et emprunte mémoire. Qu'entends-tu par « Batch pour le lancer sous les Fenêtres... » ?
:chinois: La tenue sur la durée. Tu as du remarqué comme les navs ont fort à faire pour tenir les paquets de scripts qui se balladeraient bien partout dans la RAM. Sinon, charger les URLs les + fréquentes est un bon truc pour tester fissa la compatibilité d'un navi avec ses habitudes de surf ;)[/quote]

Fenêtres ce système sensé nous ouvrir les horizons, tu connais ? Indices
Image et
Image

Commencé de tester Qupzilla (découvert sur Viperr 8 le remix #! de Fedora 23). Puis, ai compilé Brave, le nouveau navi cross-OS emmené par Brendan Eich. Je compte bien le faire passer par la case tests :)
Image
Dernière modification par kozaki le dim. 24 janv. 2016, 16:45, modifié 2 fois.
~ Configs ~ PGP Key: 1C2A554EFF0157D9
« Demande un conseil à ton ennemi et fais le contraire (proverbe juif)
SVP intéressé par tout retour d'exp. sur Arch ARM en général, et sur portable (CrOS) en particulier.
bobo
Elfe
Messages : 593
Inscription : mar. 08 avr. 2014, 22:47

Re: [script] comparer efficatité navigateurs

Message par bobo »

kozaki a écrit :Vi, puis ça aide à répondre aux flemmes qui me demandent (!) " mais que fait tel biiinchemarque ?" plutôt qu'aller voir :non:
C'est bas comme attaque. Comment je me suis fait :brice:
kozaki a écrit :Benchmarks
[…]
Du coup pour le choix des benchmarks à utiliser ?
Puisqu'utilisés comme étalon-or, on peut garder pour comparer, par exemple :
- 1 opérations de manipulation javascript -> lequel ?
- 1 HTML5 Canvas / WebGL (graphique) -> lequel ?
- 1 pour les designers -> Kaizoumark (CSS3);
- 1 généraliste -> webXPRT (javascript itou orienté manipulations sur sites Web 2.0 grand public) ou EEMBC Browsingbench (le seul qui reflète un poil le profiling en situ réelle pour l'instant).
C'est pas mal d'avoir ça sous le coude à titre de comparaison. Je verrais bien un article sur linuxfr.org, pour pointer le « paradoxe du benchmark », présenter ton approche, avoir de la critique constructive et collecter des idées.
kozaki a écrit :Que trouve tu qu'il manque aux résultats fournis par 'free' ?
En fait c'était principalement la flemme de faire des soustractions avant/après pour obtenir un nombre. Ensuite je me suis aperçu qu'il y avait moyen d'en tirer plus que ça. Maintenant que j'y pense, qu'en est-il des processus enfants du navigateurs ? y'en a-t-il ? est-ce dépendant du navigateur ? (il faudrait que je regarde)
kozaki a écrit :La tenue sur la durée. Tu as du remarquer comme les navs ont fort à faire pour tenir les paquets de scripts qui se balladeraient bien partout dans la RAM.
Ça peut être intéressant comme approche, le soucis sur la durée c'est la reproductibilité du benchmark. On peut penser à un truc genre « aspirateur de site web » qui parcourerait récursivement les pages web, en prenant les n premiers liens, charger les n pages, continuer sur la page qui présente le plus de liens. Après se pose le soucis du contenu non-statique du web, mais ça peut être un test de charge.
kozaki a écrit :Fenêtres tu connais ce système sensé nous ouvrir les horizons ?
Tu voudrais pouvoir appliquer le benchmark sur windows aussi ?
dwm — BÉPO — vim — “more is less !”
Avatar de l’utilisateur
kozaki
Chu Ko Nu
Messages : 422
Inscription : mer. 13 sept. 2006, 22:49
Localisation : London > . < Paris
Contact :

Re: [script] comparer efficatité navigateurs

Message par kozaki »

bobo a écrit :Tu voudrais pouvoir appliquer le benchmark sur windows aussi ?
Alors j'ai noté que le protocole de test des benchmarks habituels bypasse le facteur OS dans la mesure d̶'̶e̶f̶f̶i̶c̶a̶c̶i̶t̶é̶ de performance Javascript des navs. Tandis qu'un test "monde réel" lui... Tu vois ce dont il retourne ? Pour moi oui, carrément intéressant : Comparer l'efficacité, le répondant touça du même nav sur Arch, Ubuntu-Unity... et Fenêtres :) Est utilisé par des masses de gens.

L'efficacité systemland du manchot (me surprend ~tous les jours) influe-t'elle sur ma navigation ? D'ailleurs MS a finalement compris le facteur "bainchemarques" et pondu truc-Edge, qui dépôte. Sur bainchemarques.

Puis les scénarios multi-applications peuvent aider à préciser les résultats chiffrés obtenus avec un seul nav. Et à pointer des différences intéressantes. Qu'est-ce-que vous en dites ?

Enfin je dis ça, je dis rin'. et du coup, penser le scénario en batch aussi peut aider. Quelqu'un connait ? (le truc est que j'ai lâché Wiwi avant l'arrivée de MSIE7...)

Faire un papier sur linuxfr : pas bete du tout :) Après ou avant de détailler un peu sur un Gist par ex ?

PS Je réponds avec Xombrero le navi WebKit avec interface GUI ou vim-like qui pulse sur petites configs : 75" pour charger 40 pages, vif comme un chat (load average / nb. cores = .2 et empreinte RAM 205 MiB tout mouillé après config rapide, avec les 40 pages hein).

EDIT
Conso RAM Xombrero et
bobo a écrit :...la commande ps qui pourrait permettre de récupérer la conso mémoire et le temps CPU, peut-être d'autres choses. Je te conseillerais bien de regarder. Ça pourrait bien complémenter la mesure de temps ressenti avec /usr/bin/time sur le script « case&for ».

En fait c'était principalement la flemme de faire des soustractions avant/après pour obtenir un nombre. Ensuite je me suis aperçu qu'il y avait moyen d'en tirer plus que ça. Maintenant que j'y pense, qu'en est-il des processus enfants du navigateurs ? y'en a-t-il ? est-ce dépendant du navigateur ? (il faudrait que je regarde)
Merci.
la conso mémoire & l'emprinte mémoire déja faite - `ps_mem` powa :

Code : Tout sélectionner

...
2.3 Two minute
...
265.7 MiB +   4.4 MiB = 270.1 MiB       seamonkey
----------------------------------------------------------------------------
...
136.0 KiB +  70.0 KiB = 206.0 KiB       slimjet-sandbox (2)
461.9 MiB +  82.0 MiB = 543.9 MiB       slimjet (14)
Les processus enfants (yaisse faut regarder car `top` is top Bobo ;)):

2.1 Loading

Code : Tout sélectionner

...
Tasks: 145 total,   2 running, 143 sleeping,   0 stopped,   0 zombie
  PID USER      PR  NI    VIRT    RES  %CPU %MEM     TIME+ S COMMAND
 5177 kozaki    20   0  603.1m 192.0m 133.3 19.3   0:33.35 R seamonkey
 5299 kozaki    20   0    5.0m   2.6m  20.8  0.3   0:00.10 R top
 2448 kozaki    20   0   37.9m  10.3m   0.0  1.0   0:00.82 S lxsession
----------------------------------------------------------------------------
...
Tasks: 172 total,   4 running, 168 sleeping,   0 stopped,   0 zombie
  PID USER      PR  NI    VIRT    RES  %CPU %MEM     TIME+ S COMMAND
  346 kozaki    20   0  545.0m 129.0m 100.0 12.9   0:21.23 R slimjet
 1169 kozaki    20   0    5.0m   2.6m  19.4  0.3   0:00.10 R top
  972 kozaki    20   0  311.1m  60.6m   9.7  6.1   0:00.50 R slimjet
~ Configs ~ PGP Key: 1C2A554EFF0157D9
« Demande un conseil à ton ennemi et fais le contraire (proverbe juif)
SVP intéressé par tout retour d'exp. sur Arch ARM en général, et sur portable (CrOS) en particulier.
Avatar de l’utilisateur
kozaki
Chu Ko Nu
Messages : 422
Inscription : mer. 13 sept. 2006, 22:49
Localisation : London > . < Paris
Contact :

Re: [script] comparer efficatité navigateurs

Message par kozaki »

Reprise ici de mon échange avec bobo.
bobo a écrit :J'essaierais bien le semi-automatique sur une base d'améliorations du script que tu as proposé initialement. Les améliorations faciles que j'ai proposées + la validation de la fin de chargement humaine par simple clic pour choper le temps perçu par l'utilisateur. Il y a des options sympathiques de ps qui permettent de choper les processus fils. On peut envisager un kill du navigateur après le test, avec suppression du cache optionnel.

il faudrait que je réfléchisse à comment monitorer tout ça pendant le chargement des pages, en complément.

Quant aux tests multi-apps, ça me parait être bien compliqué à mettre en œuvre. Ce qui change c'est surtout la charge CPU, les accès disques et RAM en parallèle du navigateur.
kozaki a écrit :> et le script « case&for ».
À cette heure je laisse tomber le full automatique. Malgré moi, mais != test scénario monde réel.
Le full auto dépend trop des spécificités du système. Dans tous les cas le semi-automatique semble cohérent seul, et pourrait être intégré pour des tests automatiques. En quoi est-ce différent du « monde réel » ? (re-)boot -> ouverture de session -> navigateur web
En un mot: Go ! suis intéressé de voir ce que donne la voie max-automatique.

Nouvelles mesures pour adresser les flous que tu as notés bob, postées en EDIT juste au-dessus, tu les as vu ?
Aussi je MÀJ la méthode actuelle en post # 1.

Pour monitorer plus précis genre à la seconde, sar (sysstat) que j'ai testé est parfait. Et overkill pour mon objectif ;)

Non non ;) pour les scénarios réalistes multi-apps l'objectif étant identique, le profiling se fait rigoureusement comme pour les sessions Web --et pas que sur Chromium OS full cloud ;) En fait le test navigateur est issu de mon test multi-apps.

Voulais dire : le profiling de scénarios issu du "monde réel" / réaliste != bainchemarque de moteur javascript au garde à vous sans bouger.
C'est vrai que le français est moins clair que "real world" :/
bobo a écrit :Sinon pour une compatibilité « Fenêtres™ », il serait possible d'envisager un autre langage que le bash. Je ne sais pas si python est une alternative raisonnable : ça veut dire qu'il faudrait l'installer, c'est moisi. Je n'ai aucune idée des langages dispos dans les Windows récents, et ça me parait tordu de partir du C compilé pour ça. L'usage que j'en vois, c'est plutôt sur des vieux tromblons sans SSD qui ne peuvent plus tourner qu'avec une distrib' Linux. Comme tu disais dans un message : évaluer l'ensemble matériel/distrib/navigateur.
;) Je vais poser la question savoir si c'est faisable en "batch" ou "Powershell". Sinon OK pour Python : c'est pas un test de maudit tri-cliquerus, et qqn voulant mesurer l'efficacité de son choix de navi / office avec d'autres se fera pas de soucis pour installer Python.
~ Configs ~ PGP Key: 1C2A554EFF0157D9
« Demande un conseil à ton ennemi et fais le contraire (proverbe juif)
SVP intéressé par tout retour d'exp. sur Arch ARM en général, et sur portable (CrOS) en particulier.
Avatar de l’utilisateur
kozaki
Chu Ko Nu
Messages : 422
Inscription : mer. 13 sept. 2006, 22:49
Localisation : London > . < Paris
Contact :

Re: [script] comparer efficatité navigateurs

Message par kozaki »

@bobo pour monitorer précis tu peux jeter un oeil à

sar (sysstat), et

Code : Tout sélectionner

% dstat -cdnpmgs --top-bio --top-cpu --top-mem  # check 'cpu process   |  memory process'

# ps_mem [PID]   # RAM (Private + Shared)

% smem -kt   # swap
Sinon j'ai précisé les mesures faites dans le post #1 .
~ Configs ~ PGP Key: 1C2A554EFF0157D9
« Demande un conseil à ton ennemi et fais le contraire (proverbe juif)
SVP intéressé par tout retour d'exp. sur Arch ARM en général, et sur portable (CrOS) en particulier.
BlondVador
Chu Ko Nu
Messages : 302
Inscription : ven. 29 janv. 2010, 21:41

Re: [script] comparer efficatité navigateurs

Message par BlondVador »

Salut et merci pour votre travail.

J'ai légèrement amélioré votre script en y ajoutant le choix du navigateur à l'écrit. Ca évite de commenter/décommenter à chaque test ^^. Faudrait éventuellement rajouter la gestion d'erreur (si on tape un chiffre hors fourchette). Mais c'était surtout pour simplifier mes tests ^^.

Code : Tout sélectionner

#!/usr/bin/env sh
                                                                                 
# Variables
#BROWSER=chromium      # or set it on the fly
#file="urls-10"
#file="urls-40"
#USER=perru

browser_use_chromium="chromium"
browser_use_firefox="firefox"
browser_use_lightfirefox="lightfirefox"
browser_use_midori="midori"
browser_use_xombrero="xombrero"

# -----[ part 0 ]------

# 1- chromium
# 2- Firefox
# 3- lightfirefox
# 4- midori
# 5- xombrero

echo "Tappez le numéro du navigateur que vous souhaitez benchmarker :"
echo "1/ Chromium"
echo "2/ Mozilla Firefox"
echo "3/ Lightfirefox"
echo "4/ Midori"
echo "5/ Xombrero"
echo ""

read browser_num

if [ $browser_num == "1" ]; then
	BROWSER="$browser_use_chromium"

elif [ $browser_num == "2" ]; then
	BROWSER="$browser_use_firefox"

elif [ $browser_num == "3" ]; then
	BROWSER="$browser_use_lightfirefox"

elif [ $browser_num == "4" ]; then
	BROWSER="$browser_use_midori"

elif [ $browser_num == "5" ]; then
	BROWSER="$browser_use_xombrero"
fi

# -----[ part 1 ]------

info="$(pwd)/$file-$(hostname)-$(uname -rms)-$BROWSER-$(date +%Y%m%d_%H%M).txt"

# 1. Utime & RAM before; launch the browser:
echo -e "1) Before\n$(uptime)\n$(free -m)\n"   > "$info"
$BROWSER

# -----[ part 2 ]------

# 2. Load the URLs, waiting 2 sec between each for sanity
#
# Mozilla
if [ $BROWSER == "firefox" ]; then
	for line in $(cat $file); do "$BROWSER" -new-tab "$line" & 2>/dev/null; sleep 2; done

# Google Chrome/ium & Lightfirefox
elif [[ ( $BROWSER == "chromium" ) || ( $BROWSER == "lightfirefox" ) ]]; then
	for line in $(cat $file); do "$BROWSER" --new-tab "$line" & 2>/dev/null; sleep 2; done

# Midori
elif [ $BROWSER == "midori" ]; then
	for line in $(cat $file); do "$BROWSER" -e open-new-pages-in "$line" & 2>/dev/null; sleep 2; done

# Xombrero (requires 'socket' on in the conf file)
elif [ $BROWSER == "xombrero" ]; then
	for line in $(cat $file); do $BROWSER -n "$line" & 2>/dev/null; sleep 2; done
fi

# 2.1: CPU, la / wa & RAM usage while loading ('echo -e' below removed for readability)
sleep 5;                                                                        
$(top -b -n 1 | head -3)  >> "$info"

sleep 30;
top -b -n 1 | head -5 && free -m >> "$info"

sleep 60;
top -b -n1 -U "$USER" && free -m   >> "$info"

# 2.4 (urls-40): ~three minutes after launching the $BROWSER:
sleep 60;
top -b -n1 -U "$USER" && free -m  >> "$info"

# 2.5 (urls-40): ~five minutes after launching the $BROWSER:
sleep 120;
top -b -n1 -U "$USER" && free -m   >> "$info"
                                                                                 
# 3. Close the $BROWSER & RAM after
pkill -15 $BROWSER
sleep 10;
free -m  >> "$info"

# If the script does not work for some reason just do it on the cmd line         

# Thanks @ hamsolo474
Répondre