• [^] # Re: Oui, mais c'est pas forcément le bon outil

    Posté par . En réponse à la dépêche Moteur de blog fBlog. Évalué à 8. Dernière modification le 15 mars 2015 à 18:30.

    J’ai dimensionné fBlog sur la base d’un blogueur hypothétique qui posterait un billet par jour sur 50 ans. Si l’on multiplie 365 jours X 50 ans, ça fait déjà 18250 permaliens [...] Mes tests sur un vieil ordinateur me donnent moins de une minute de traitement avec fBlog.

    En même temps ça serait inquiétant que ça ne soit pas le cas. fBlog ne fait RIEN. Grosso modo il rajoute un header et un footer à des fichiers texte et maintient trois pauvres index. C'est entièrement IO bound et ça ne peut pas être lent au delà des lectures et écritures de fichier.

    Commençons par créer le blog 365 * 50:

    $ ./bin/linux_x86_64/fblog --create-blog
    $ ./bin/linux_x86_64/fblog -a
    # Création d'un post de ~2K lignes
    $ wc -l fBlog/data/20150315100011.blog
    2002 fBlog/data/20150315100011.blog 
    $ for i in $(seq -w 5 1 18250) ; do cp fBlog/data/20150315171935.blog fBlog/data/201503151$i.blog ; done

    Maintenant regardons le temps écoulé dans les cas suivants:

    Avec sync:

    • SSD cache VFS froid: real 0m21.782s, user 0m3.113s, sys 0m5.580s
    • SSD cache VFS chaud: real 0m7.295s, user 0m2.046s, sys 0m1.694s
    • HDD cache VFS froid: real 4m45.585s, user 0m4.287s, sys 0m8.237s
    • HDD cache VFS chaud: real 0m14.243s, user 0m2.043s, sys 0m1.736s

    Sans sync:

    • SSD cache VFS froid: real 0m18.116s, user 0m3.144s, sys 0m5.464s
    • SSD cache VFS chaud: real 0m3.745s, user 0m2.150s, sys 0m1.584s
    • HDD cache VFS froid: real 4m44.260s, user 0m4.174s, sys 0m8.174s
    • HDD cache VFS chaud: real 0m3.802s, user 0m2.108s, sys 0m1.694s

    Les mesures sont prises ainsi

    $ sync ; time (./bin/linux_x86_64/fblog -u ; sync) 
    
    $ time ./bin/linux_x86_64/fblog -u 
    

    Pour vider le cache VFS

    # echo 3 > /proc/sys/vm/drop_caches
    

    Je passe l'analyse plus poussée. Tu peux jouer avec perf ou plein d'autres choses pour voir ou passe le temps en espace noyau et utilisateur.

    Tu pourrais utiliser un langage qui repose sur une VM à base de lutin en grève ça ne changerait rien au temps d'exécution, le logiciel ne fait virtuellement rien.

    fBlog tiendra la charge seulement quelques années (alors il faudra bien me remettre au code et étudier la parallélisation des tâches qui est l’un des dadas du langage Fortran).

    Paralléliser ne changera rien tu es IO bound.

    Ton approche de tout refaire peut très bien être justifiée. C'est un bête moteur de blog ! Maintenant si tu voudrais améliorer les perfs, la seule option c'est de faire moins de travail. C'est à dire ne pas refaire bêtement du travail déjà fait.

    Bon en vrai on s'en balance. C'est un moteur de blog statique, la génération est faites une seule fois en asynchrone...

    Et une fois que tu connais ton markup et les index que tu veux maintenir, la génération ca se recode dans la journée dans à peut prêt n'importe quel langage.

    PS: Ton archive ça serait mieux si elle ne pourrissait pas le répertoire courant quand tu l'extrais.