- 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
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.benchmark a écrit :please close other browsers, tabs and make sure your screen stays awake the whole time during the test.
Spoiler :
Scores bainchemarques Browsermark, Jetstream et Octane 2 (higher is better)
...Temps en seconde pour charger 10 pages (et un email, soyons fous)
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 !-)
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
- 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.
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
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.