Journal Accélération de firefox sur support lent

Posté par .
Tags : aucun
13
7
avr.
2009
Bonjour, Nal,

J'utilise une distrib linux sur clé USB, ce qui est fort pratique.
Toutefois, j'ai quelquefois des lenteurs, différentes selon les produits.

Firefox fait office de champion. Extrêmement long au démarrage, fréquents blocages lors du surf, lentissimes lors de l'utilisation de l'awesome bar, en un mot inutilisable.

Je me suis rendu compte que toutes ces lenteurs étaient dûes au support (USB + encryption). J'ai eu l'idée donc de mettre tout .mozilla/firefox en tmpfs afin d'accélérer les choses.
Et ça marche, c'est même très rapide. Problème, tout l'historique, la config, etc est perdu au redémarrage.

J'ai donc écrit un script ffirefox (pour fast firefox) qui prend le contenu de
.mozilla/firefox, le sauvegarde, monte un tmpfs sous .mozilla/firefox, réinjecte le contenu et lance firefox. L'opération inverse est faite à l'arrêt.
J'en profite pour supprimer le cache et optimiser les bases .sqlite de mon profil.

firefox est redevenu utilisable (et il est très rapide).

Je soumet le script à votre sagacité, amis lecteurs, afin que vous puissiez me dire si j'ai raté quelquechose, si vous avez d'autres idées d'optimisations, ou si ça vous plaît:

#! /bin/bash

#script fast firefox. L'idée est de mettre en RAM ~/.mozilla/firefox
# 1. on sauvegarde tout sauf le Cache
# 2. on monte le répertoire firefox en tmpfs
# Pour cela, fstab doit contenir une ligne
# tmpfs /home/octane/.mozilla/firefox tmpfs noauto,uid=octane,user,mode=700 0 0
# 3. on detarre le contenu qui se trouve donc en RAM
# on optimise les bases sqlite3
# A la déco, on recommence, en sens inverse.
# j'ajoute des xmessage afin d'expliquer ce que fait le script

launch_ffirefox () {
xmessage -center "Launching fast firefox.. Please Wait" &
#checking if my little hack is not allready in use
if ! mount | grep "/home/octane/.mozilla/firefox" > /dev/null
then
#Good thing
echo "tmpfs is not mounted"
#checking if firefox is not in use
if ps ax | grep firefox-bin | grep -v grep > /dev/null
then
#do nothing
echo "do nothing"
else
#ok, time to go on
cd /home/octane/.mozilla
rm -f firefox/Cache/*
[ -f ff.tgz ] && rm ff.tgz
tar cvfz ff.tgz firefox/
mount /home/octane/.mozilla/firefox
tar xvfz ff.tgz
for f in ~/.mozilla/firefox/*/*.sqlite; do sqlite3 $f 'VACUUM;'; done
killall xmessage
/usr/bin/firefox $@
fi
else
#do nothing
echo "tmpfs is mounted"
fi
}

cancel_ffirefox () {
xmessage -center "Stopping firefox, please Wait.." &
#We should have been launched by this script.
cd /home/octane/.mozilla/
rm -f firefox/Cache/*
[ -f ff.tgz ] && rm ff.tgz
tar cvfz ff.tgz firefox/
umount /home/octane/.mozilla/firefox
tar xvfz ff.tgz
killall xmessage
}

#Now we can launch this script
launch_ffirefox
cancel_ffirefox
  • # sqlite

    Posté par . Évalué à 5.

    Firefox sauve régulièrement son historique pour qu'il le retrouver en cas de crache dans une base SQLlite. Or cette base fait souvent des opération sync() qui sont une tuerie d'un point de vue performance IO. Il me semble que Firefox 3.5 change ce comportement.

    Je crois qu'il existe aussi une clef de configuration pour changer cette manière de faire au détriment de la sécurité des données.

    "La première sécurité est la liberté"

    • [^] # Re: sqlite

      Posté par . Évalué à 4.

      Pour plus d'infos :
      http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/

      "La première sécurité est la liberté"

    • [^] # Re: sqlite

      Posté par . Évalué à 5.

      Or cette base fait souvent des opération sync() qui sont une tuerie d'un point de vue performance IO.

      Maintenant que tout est en RAM, les performances sont très acceptables.

      Je crois qu'il existe aussi une clef de configuration pour changer cette manière de faire au détriment de la sécurité des données.

      En fait, en cas de crash, avec ma méthode, on retombe sur un état sain (puisque les fichiers originaux sont toujours en place).
      Je risque juste de perdre mon dernier historique.

      Mais ça se tente, si quelqu'un connait cette clé (ou d'autres) permettant d'accélérer les perfs, je prends
  • # Le mode verbose

    Posté par (page perso) . Évalué à 9.

    est-il vraiment nécessaire d'utiliser le mode verbose pour les tar ?

    tar cvfz
    tar xvfz

    Le mode verbose fait des entrées-sorties inutiles. C'est pratique pour du debug mais pas plus.
    • [^] # Re: Le mode verbose

      Posté par (page perso) . Évalué à 5.

      Je confirme que sur des archives contenant beaucoup de petits fichier, ça peut multiplier le temps de décompression par 2 ou 3... C'est du vécu.
      • [^] # Re: Le mode verbose

        Posté par . Évalué à 4.

        J'ai énormément grossi mon script pour linuxfr afin qu'il soit le plus lisible possible.
        (comme par exemple les echo "je ne fais rien")

        Mais oui, ça fait perdre du temps. Curieusement, le plus gros ralentissement chez moi lors de l'utilisation d'un tar zxvf est dû au xterm.
        100% CPU pour le xterm. Si je réduis le xterm, ça detarre bien plus vite.
        • [^] # Re: Le mode verbose

          Posté par (page perso) . Évalué à 7.

          ben c'est normal non? il faut bien gérer l'affichage de toutes ces charmantes petites lignes qui défilent.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Quelle distrib ?

    Posté par (page perso) . Évalué à 2.

    J'utilise Toutou Linux sur clé Usb (sans chiffrer) et c'est tout à fait bon.

    Et mon PC n'est pas une bête de course, mais ce modèle
    http://www.norhtec.com/products/mcsr/index.html

    If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

    • [^] # Re: Quelle distrib ?

      Posté par . Évalué à 2.

      Toutou linux est déjà optimisé pour un support USB...

      J'utilise une slackware12.2 sur un Acer Aspire One.

      Le chiffrement consomme pas mal (j'ai souvent le kcryptd dans les process qui s'affole). L'utilisation d'ext3 est abominable (mais vraiment, du genre tu t'endors avant la fin du boot). L'utilisation d'ext2 va bien.

      La lenteur était surtout ressentie avec firefox.
      J'ai fait des essais avec openoffice3, et pas de problèmes.
      J'ai encore des lenteurs au chargement de XFCE; mais au démarrage seulement, rien ensuite.

      J'hésite à mettre d'autres répertoires en tmpfs comme /var/run ou /var/lock, ou des journaux messages.
      • [^] # Re: Quelle distrib ?

        Posté par (page perso) . Évalué à 3.

        Très bien ton script.

        Je suppose que tu as déjà lu
        http://petaramesh.org/post/2008/09/01/Noyau-2627-Ubuntu-cust(...)
        et
        http://petaramesh.org/post/2008/08/24/Noyau-Ubuntu-custom-po(...)

        qui parle aussi de performance sur ce modèle

        :-)

        If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

      • [^] # Re: Quelle distrib ?

        Posté par . Évalué à 2.

        c'est quoi l'intérêt du chiffrement de firefox ?

        Pourquoi ne pas chiffrer uniquement les données personnelles importantes ?

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Quelle distrib ?

          Posté par . Évalué à 4.

          c'est quoi l'intérêt du chiffrement de firefox ?

          Ce n'est pas firefox qui est chiffré, mais la clé USB. Donc de facto, firefox est situé sur un support chiffré.

          Je me suis inspiré d'un article de linux magazine qui parlait du chiffrement de disque sous linux. Absolument _tout_ est chiffré. Chiffrer /home m'apparait hautement insuffisant. On ne sait jamais ce que contient /tmp ou /var/tmp ou /var/spool par exemple.

          J'ai donc utilisé une clé USB de 4Go que j'ai coupé en deux:
          900Mo en VFAT (/dev/sda1) en clair (qui contient le chargeur de boot, le noyau et l'initramfs)
          le reste en ext2 chiffré (soit 2.8Go car les clés ne font pas 4Gio, mais 4Go)

          Je détecte au boot si sur le disque local il y a une partition SWAP. Si oui, je chiffre, je mkswap et je l'utilise (a l'extinction, je fais l'inverse, je ferme le device chiffré, et je refais un mkswap sur le device réél) [1]

          Donc absolument toute ma distribution est chiffrée, je peux utiliser la clé USB sur n'importe quelle machine (BSD, mac, et même windows, sisi) pour échanger des fichiers en clair à l'aide de la partition VFAT

          J'ai fait le choix du chiffrement pour pleins de raisons que je n'évoquerai pas ici, en sachant bien que ça impacterait un peu les perfs.

          [1] Cela peut poser des problèmes si je me branche sur une machine en hibernation. Le système est hiberné dans le swap, j'arrive, j'explose tout, je m'en vais, et le reboot de la machine d'origine passera mal :-)
          je m'en vais améliorer le truc. Question: comment savoir qu'une partition swap a servi pour hiberner un système?
  • # Dans mon cas

    Posté par (page perso) . Évalué à 1.

    J'ai rencontré le même souci (dans le cadre d'une installation sur Compact Flash) mais j'ai abandonné firefox, par contre Opera semblait un peu trop écrire sur le disque même avec le cache disque désactivé (il devait synchroniser l'historique je présume), du coup je l'ai aussi mis sur un disque RAM, que je resynchronise à la fermeture, ce qui hélas prends pas mal de temps à faire le sync. Faudrait que je nettoie le .opera un de ces jours.

    Bon en fait c'est pas ça dont je voulais parler. Mon souci premier c'est que ma debian semble avoir beaucoup de mal avec le disque en compact flash. Depuis quelques temps, la machine ne s'éteinds plus correctement, ça donne un écran noir et ça reste planté comme ça, je suis obligé de forcer le halt avec le bouton power. Du coup au prochain boot je me tape un check de la partoche et là c'est la catastrophe, ext2 est un système de fichiers qui semble extraordinairement mauvais. Souvent des fichiers disparaissent, voir des répertoires entiers. J'ai récemment perdu tous mes mails comme ça (heureusement que j'ai un backup).

    Bon heu du coup si quelqu'un a un tuyau pour sécuriser un peu mieux mes données, je dis pas non...

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Dans mon cas

      Posté par . Évalué à 1.

      Utilises ext3 déjà. Ensuite, il faut être sûr de sa CF et de savoir les modes de transfert qu'elle supporte correctement.

      "La première sécurité est la liberté"

      • [^] # Re: Dans mon cas

        Posté par . Évalué à 2.

        Utilises ext3

        Been there, done that.
        Comme indiqué, la batterie à le temps de se vider que l'écran de login n'est pas arrivé. C'est inexploitable. Complètement.

        De plus, l'écriture du journal risque de "tuer" extremement rapidement la flash. C'est un fichier, situé toujours à la même place qui est écrit en permanence.
        (ext4 améliore ce point, à ce sujet)

        Par contre, comment connaitre : les modes de transfert qu'elle [la clé USB] supporte correctement ? Là, ça m'intéresse.
        • [^] # Re: Dans mon cas

          Posté par (page perso) . Évalué à 1.

          Oui non ext3 c'est mauvais pour le support c'est clair.

          Pour les modes de transferts, je présume qu'il parle d'udma etc. Du coup un peu de hdparm -i /dev/hda te donnera les infos utiles. Par exemple là au bureau sur mon disque dur : UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6

          L'étoile indique le mode utilisé en ce moment, si c'est pas le plus rapide c'est que y'a un souci (mais tu peux pas forcément y faire quelque chose).

          Enfin c'est pas de là que vient mon souci à moi je pense...

          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # ca marche bien...

    Posté par . Évalué à 3.

    j'ai juste modifié ton script pour qu'il soit utilisable par tout utilisateur qui serait sudoer
    mais qui ne voudrait pas modifier son /etc/fstab

    ci-dessous la version (bavarde avec les echos et les tar *vf...)

    #! /bin/bash

    #script fast firefox. L'idée est de mettre en RAM ~/.mozilla/firefox
    # 1. on sauvegarde tout sauf le Cache
    # 2. on monte le répertoire firefox en tmpfs
    # Pour cela, fstab doit contenir une ligne
    # tmpfs /home/octane/.mozilla/firefox tmpfs noauto,uid=octane,user,mode=700 0 0
    # 3. on detarre le contenu qui se trouve donc en RAM
    # on optimise les bases sqlite3
    # A la déco, on recommence, en sens inverse.
    # j'ajoute des xmessage afin d'expliquer ce que fait le script

    launch_ffirefox () {
    xmessage -center "Launching fast firefox.. Please Wait" &
    #checking if my little hack is not already in use
    if ! mount | grep "~/.mozilla/firefox" > /dev/null
    then
    #Good thing
    echo "tmpfs is not mounted"
    #checking if firefox is not in use
    if ps ax | grep firefox-bin | grep -v grep > /dev/null
    then
    #do nothing
    echo "do nothing"
    else
    #ok, time to go on

    ## optimizing sqlite database before backup
    for f in ~/.mozilla/firefox/*/*.sqlite; do sqlite3 $f 'VACUUM;'; done

    ## purging cache before backup
    cd ~/.mozilla
    rm -f firefox/Cache/*
    [ -f ff.tgz ] && rm ff.tgz

    ## backup
    tar cvfz ff.tgz firefox/

    ## activating tmpfs (requiere sudo right)
    sudo mount -t tmpfs tmpfs ~/.mozilla/firefox
    tar xvfz ff.tgz

    ## real launch
    killall xmessage
    /usr/bin/firefox $@
    fi
    else
    #do nothing
    echo "tmpfs is mounted"
    fi
    }

    cancel_ffirefox () {
    xmessage -center "Stopping firefox, please Wait.." &
    #We should have been launched by this script.

    ## purging cache
    cd ~/.mozilla/
    rm -f firefox/Cache/*
    [ -f ff.tgz ] && rm ff.tgz

    ## backup of tmpfs
    tar cvfz ff.tgz firefox/

    ## deactivating tmpfs
    umount ~/.mozilla/firefox

    ## restore firefox files
    tar xvfz ff.tgz
    killall xmessage
    }

    #Now we can launch this script
    launch_ffirefox
    cancel_ffirefox
    • [^] # Re: ca marche bien...

      Posté par . Évalué à 2.

      evidemment vous aurez corrigé la ligne
      ## deactivating tmpfs
      umount ~/.mozilla/firefox


      en
      ## deactivating tmpfs
      sudoumount ~/.mozilla/firefox


      ca sinon ca ne demonte pas le tmpfs
  • # très bien mais...

    Posté par (page perso) . Évalué à 2.

    c'est super ce script. je vais commencer à l'essayer même sur mon desktop parce que ça commence à me prendre la tête les 3 secondes 5 secondes parfois 10 secondes d'attente en surfant dès qu'il y a un peu d'IO en cours quand je surfe qui fait bloquer firefox...

    moi j'ai ~/.mozilla/firefox/"uncode".default/Cache

    donc j'ai du changer la ligne
    rm -f firefox/Cache/*
    en
    rm -f firefox/*/Cache/*

    j'aime pas xmessage. pouah... rien du tout c'est aussi bien.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.