on ne peut pas en dire autant des moteurs de blog statiques (enfin, ceux qui tiennent vraiment la route).
De tête Jekyll, Pelican et quelques dizaines d'autres dont j'ai oublié le nom. Je t'avoue que c'est pas ma passion.
mettre les deux liens des pages précédentes et suivantes [...] Pour les index [...] Et ça c'est du traitement de données internes. Pas du I/O.
Arrête. On parle d'indexer 18K dates pour en sortir:
pointeur suivant / précédent
une structure hiérarchique par jour et mois
Ca consomme 0 en ressource. Ton CPU à une éternité pour faire ça pendant que les IO font du slow motion. Grosso merdo en étant large, si t'y passes plus de quelques μs par entrée y'a un soucis quelque part (ou il y a un truc non trivial que j'ai loupé).
Ce n'est aucunement une critique du projet ou de la réalisation. C'est juste une réalité technique de la problématique. Pas mal de gens l'on oublié mais un CPU ça va vite quand on l'utilise correctement.
J'attends avec impatience ces nouveaux tests !
Je ne refais pas les différents tests puisque tout ce qui va changer c'est la conso CPU en espace utilisateur.
Prenons deux billets par jour pendant un siècle:
$ for i in $(seq 1915 2015) ; do for j in $(seq -w 2 01 12) ; do for k in $(seq -w 2 01 28) ; do cp source.blog $i$j${k}000000.blog ; done ; done ; done
$ for i in $(seq 1915 2015) ; do for j in $(seq -w 2 01 12) ; do for k in $(seq -w 2 01 28) ; do cp source.blog $i$j${k}120000.blog ; done ; done ; done
Regardons ce que ça donne
$ time perf record -F 99 -g -- ./src/fblog -u
[...]
[22:12:36.366] 59994 permalink pages built
[22:12:36.366] Make monthly archive pages to `fBlog/export_html/ccyymm.html'
[22:12:55.384] 1111 monthly archive pages built
[...]
61111 files generated within the subdirectory `fBlog/export_html/'
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.330 MB perf.data (~14428 samples) ]
real 0m30.856s
user 0m20.956s
sys 0m4.891s
$ perf script | stackcollapse-perf.pl | flamegraph.pl > out.svg
Et visualisons le CPU flamegraph résultant (cliquer sur ce lien pour l'avoir en dynamique)
Flamegraph
Donc à a vue de pif dans ce cas tu passes 20% du temps on CPU dans la fonction html_month_archive. En l'optimisant tu gagneras au mieux 20%. J'ai survolé le code 11s mais j'ai du mal à voir ce qui peut demander un algo en n3 pour faire un index par mois. Après comme je l'ai déjà dit, ton truc fait très largement le job.
PS: je t'ai trouvé un bug. Si le nombre de fichier dans export_html dépasse le nombre d'argument supporté par la ligne de commande tu plantes (sh: /usr/bin/rm: Argument list too long).
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par ckyl . En réponse à la dépêche Moteur de blog fBlog. Évalué à 3.
De tête Jekyll, Pelican et quelques dizaines d'autres dont j'ai oublié le nom. Je t'avoue que c'est pas ma passion.
Arrête. On parle d'indexer 18K dates pour en sortir:
Ca consomme 0 en ressource. Ton CPU à une éternité pour faire ça pendant que les IO font du slow motion. Grosso merdo en étant large, si t'y passes plus de quelques μs par entrée y'a un soucis quelque part (ou il y a un truc non trivial que j'ai loupé).
Ce n'est aucunement une critique du projet ou de la réalisation. C'est juste une réalité technique de la problématique. Pas mal de gens l'on oublié mais un CPU ça va vite quand on l'utilise correctement.
Je ne refais pas les différents tests puisque tout ce qui va changer c'est la conso CPU en espace utilisateur.
Prenons deux billets par jour pendant un siècle:
Regardons ce que ça donne
Et visualisons le CPU flamegraph résultant (cliquer sur ce lien pour l'avoir en dynamique)
Flamegraph
Donc à a vue de pif dans ce cas tu passes 20% du temps on CPU dans la fonction
html_month_archive. En l'optimisant tu gagneras au mieux 20%. J'ai survolé le code 11s mais j'ai du mal à voir ce qui peut demander un algo en n3 pour faire un index par mois. Après comme je l'ai déjà dit, ton truc fait très largement le job.PS: je t'ai trouvé un bug. Si le nombre de fichier dans export_html dépasse le nombre d'argument supporté par la ligne de commande tu plantes (
sh: /usr/bin/rm: Argument list too long).