*/ ouep, tu gères certaines choses qui vont modifier le contenu (ou le contenant ;) ) des pages, donc il faudra regénérer le cache si ces choses bougent... Personellement, je stoque certaines choses concernant les pages en cache dans une table de hachage stoquée sur le disque (come j'ai la chance de travailler en perl, j'utilise des dbm*), je met à jour les infos à chaque fois qu'une page est générée, et le daemon lit dedans pour décider quoi faire... Mais j'ai aussi certaines actions (quand on rajoute/modifie un enrengistrement dans certaines tables) qui mettent à jour le cache par évènements, histoire d'optimiser un peut... Mais ca n'est pas réalisable pour tout.
*/ sinon oui, le site dont je parles est comparable avec Linuxfr sur le fait qu'il est hautement dynamique, mais aussi sur le fait qu'il a une grosse DB de données antérieures (que les clients peuvent rapeller), qu'il a beaucoup de hits (plus de 2* plus que LinuxFR à prioris), et qu'il a des affiliés (dont des gros noms) qui affichent le même contenu mais avec leur propre 'skin', et ce depuis ce serveur...
*/ pour la taille du cache, personellement j'avais penssé (si le problème se présentait) à un daemon qui surveille la création de fichiers dans le répertoire grace à imon/fam/cequetuveux... C'est un peut lourd, puissequ'il vérifie à chaque fois qu'un fichier est créé dans le répertoire du cache, mais au moins, tu peut pas te faire rouler, et tu gères bien ;)
*/ VFS/FS : C'est vrai que la lecture est très performante sous linux (surtout sur un serveur, qui a du raid, ou du SCSI, ou au moins du bon IDE optimisé avec hdparm), mais franchement, tu peux pas me faire croire que la lecture (ou pire : l'écriture) est aussi rapide sur un HDD que dans la ram. Le paliatif que j'ai trouvé, c'est de foutre le cache de ce site sur une partoche reiserfs, où la lecture est très rapide, et où la quantitée de fichiers dans le répertoire n'est pas un obstacle... Et je sent très clairement des différences de perfs entre ext2/3 et reiser...
[^] # Re: Euh...
Posté par _PinG _ . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 1.
*/ sinon oui, le site dont je parles est comparable avec Linuxfr sur le fait qu'il est hautement dynamique, mais aussi sur le fait qu'il a une grosse DB de données antérieures (que les clients peuvent rapeller), qu'il a beaucoup de hits (plus de 2* plus que LinuxFR à prioris), et qu'il a des affiliés (dont des gros noms) qui affichent le même contenu mais avec leur propre 'skin', et ce depuis ce serveur...
*/ pour la taille du cache, personellement j'avais penssé (si le problème se présentait) à un daemon qui surveille la création de fichiers dans le répertoire grace à imon/fam/cequetuveux... C'est un peut lourd, puissequ'il vérifie à chaque fois qu'un fichier est créé dans le répertoire du cache, mais au moins, tu peut pas te faire rouler, et tu gères bien ;)
*/ VFS/FS : C'est vrai que la lecture est très performante sous linux (surtout sur un serveur, qui a du raid, ou du SCSI, ou au moins du bon IDE optimisé avec hdparm), mais franchement, tu peux pas me faire croire que la lecture (ou pire : l'écriture) est aussi rapide sur un HDD que dans la ram. Le paliatif que j'ai trouvé, c'est de foutre le cache de ce site sur une partoche reiserfs, où la lecture est très rapide, et où la quantitée de fichiers dans le répertoire n'est pas un obstacle... Et je sent très clairement des différences de perfs entre ext2/3 et reiser...