Voici les points importants du changelog (déjas écrit dans un de mes journaux) :
*/ Support Active Directory (w2k, XP, w2k3...)
*/ Support de l'unicode
*/ Réécriture du système d'authentification (notement plus configurable)
*/ Mailleure gestion des erreurs
*/ Meilleure gestion de l'impression
*/ Performances globales améliorées
*/ Migration NT4->Samba facilitée
*/ Gestion des relations d'aprobations avec les DC NT4
*/ Gestion des signatures (w2k3)
*/ Documentation revue
d'après le maintainer du paquet sur la sid : Description: Matrix-based scientific software package (a la Matlab and Xmath)
Scilab is a matrix-based scientific software package
resembling Matlab and Xmath. Scilab contains hundreds of
built-in mathematical functions, rich data structures
(including polynomials, rationals,linear systems, lists,
etc...) and comes with a number of specific toolboxes for
control, signal processing, ...
C'est libre d'après les auteurs, mais pas d'après les Debian Guidelines... Mais c'est toujours plus open-source que mathlab ;)
C'est développé par l'inria, donc en plus c'est Francais.
tant que l'on est dans le p2p de recherche, on pourais utiliser un système de partage de bookarks. En gros une sorte de DMOZ distribué, mais qui pourais aussi servir à modifier le pagerank d'une page en fonction du nombre de bookmarks qui pointent dessus ...
Le tout basé sur un système de réseau de confience par exemple...
Mais les problèmes que je voit sont :
*/ Il faut déjas un bon nombre de nodes au réseau pour stoquer (avec redondance, attention) une DB dans laquelle faire des recherches
*/ Il y a le risque que dans certaines conditions, une recherche n'ai pas accès à la totalitée de la DB, d'où un problème de validité de l'ordre du résultat...
Il faudrait donc des serveurs Internet constament présents, qui stoquent la DB, qui distribuent aux nodes p2p des recherches/parsing à effectuer, qui récoltent les réponses, et qui distribuent aussi à chaque connecté une partie de la DB, afin de répartir les recherches. Mais si une partie de la DB est innacessible, bah on tapes dans la DB des derveurs principaux, ou de leur mirors...
Après, l'aspect réseau de confiance est très important selon moi, ne serai-ce que pour valider les résultats retournés...
c'est mon premier journal, et je croyais que comme les news, on pouvais mettre les url dans des cases en bas... Après en visualisant, j'ai oublié et voilà... On mettra ca sur une erreur de jeunesse dans les journaux.
Il est même possible de diffuser des morceaux "Open Source"...
soundtracker est un module tracker qui génère des fichiers XM, qui contiennent une sorte de "partition" de petits samples wav qui vont composer un morceau.
C'est un programme simpa à utiliser, il ressemble à beaucoup de trackers connus issus du monde dos/windows...
Soundtracker : http://www.soundtracker.org/
Voir le site http://www.united-trackers.org/ pour des informations complémentaires sur les trackers, les modules et tout ca...
le débit théorique annoncé n'est que le débit maximum supporté au niveau matériel... au-dessus, d'autres couches limitent le débit dans la pratique - voir le principe de l'architecture OSI
En même temps si ce sont les couches logicielles limitatives dans le modèle OSI (donc 5 des 7 couches), on n'ateindrait jammais le Gigabit. La limitation ne viens pas du tout d'un ralentissement due aux couches logicielles, du moins pas dans la majorité des cas...
(avec tralala = ton disque)
Regarde si un des champs ne contiens pas une valeure qui pourait être la température (entre 40 et 60° environ selon la disposition et la ventilation...)
Moi ca ne marche pas (encore) avec un Western Digital... Je dis pas encore parceque j'ai l'impression que le champ 9 donne quelquechose qui pourait ressembler à la température... Il faudrait que j'éteignes la machine, que je vois si la valeure est plus faible au départ, si elle monte, et éventuelemnt déplacer un ventillateur pour laisser le HDD chauffer un peut pour voir... Auquel cas je ferais un report...
Sinon, mon IBM est à 53° (uptime d'1 semaine, pas spécialement ventillé, asser utilisé car c'est mon /home)
hummm... bon, déjas si tu est en DHCP et que ce fameux DHCP te fournit des DNS, alors oui, le fichier est écrit. Ton client dhcp vas écrire les dns dans ce fichier...
Sinon il y a peut-être un problme physique à cet endroit du disque... il faudrait essayer de s'arranger pour que ce fichier soit placé à un autre endroit du disque...
bah perso, le fait qu'il faille un gros plugin tout moche pas ergonomique du tout et qui prends plein de place juste pour rechercher dans la liste, ca me déplais... Et personellement, je préfères une gestion de playlist à la rhythmbox ;)
Mais ca n'engage que moi, et en contrepartie, il a pas mal d'avantages (pas mal de plug-ins, ...)
ouaip, lftp est mon client ftp de référence...
Il a trop de truc pratique, genre l'attente de la fin d'un dl, les downloads concurents, la mise en bg au cas ou la cnx ssh pète et qu'on ait pas penssé à screen... Y'a rien à dire, lftp c'est du très bon boulot...
bah en fait, ca marche avec mon vieux cfg de duke, mais dès que je map les touches de direction/straff sur zqsd (habitude prise avec UT et quake), je perds le mouse aiming :'(
Tu utilise quelles touches pour la direction?
ouep, on atteins un truc vraiement très agréable avec les dernières CVS...
Le resampling marche impec (la vois de duke était en 4k :/), c'est super fluide (normal me direz-vous).
J'ai encore quelques problèmes avec la souris (selon le binding des touches, je perds le mouse-aiming ce qui fait que l'axe vertical de la souris ne fait qu'avancer/reculer Duke...), mais ca viens peut-être du fait que je change le cfg à la main (SETUP.EXE fait planter mon dosemu/freedos :/ )
Et pour ceux qui n'ont pas la atomic, ca marche avec la version shareware now...
http://www.fileplanet.com/index.asp?file=35964
Du pur bonheur...
Sinon, pour la conversion asm->C, ce n'est pas que pour le mac, c'est histoire de supporter toutes les archis immaginables... A nous les pda et autres...
oui, surtout depuis les derniers noyeau, mais principalement pour les fichiers beaucoup utilisés... Hors ce qu'il y a d'interessant avec le tmpfs (en plus de la vitesse d'écriture), c'est la disponibilité du fichier instantanément en Ram, cad qu'un fichier qui n'est pas demandé souvent (on vas dire qui n'as pas été demandé depuis une heure pour être presque surs ;)) est quand même dispo instantanément. Exit les temps d'accès disques... Et si tu multiplies ca par 100 ou par 1000, bah ca fait la différence. De toute facon, je ne pensse pas que cache 'statique' serveur tmpfs soit nécessaire, mais bon, chacun fait ce qu'il veut ;)
Sinon, reiser est plus rapide de facon générale, BEAUCOUP plus rapide sur les petits fichiers (oui, on peut dire que les pages HTML rentrent dans cette cat...), et ENORMEMENT plus rapide pour les répertoires qui ont beaucoup de fichiers (un cache HTML par exemple, surtout si il est à un seul niveau...). Et je te promet que sur le site dont je te parles, reiserFS a fait une très nette différence pour le cache... J'ai l'exemple d'un gros serveur de mail aussi qui doit son salut à reiserFS...
*/ 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...
Alors, je vais répondre à tes questions aussi clairement que possible :
*/ Je comprendrais jamais pourquoi l'invalidation du cache n'est pas relier à la modification des données qu'il contient : C'est le cas de certains systèmes de cache (templeet par exemple, mais aussi mon système de cache dont je parles dans le post précédent...). Mais certaines données sont volatiles dans la durée, ou selon d'autres critères (nombre d'affichages, ...), c'est le cas -par exemple-d'une page d'accueil de news qui ne présente que les news du jour (Ce que l'on apelle "a la une" ou "édition quotidienne"). De plus, dans certains cas (particuliers), le déploiement du cache est indépendant du code du site, auquel tu n'as pas toujours accès, ou que tu n'as pas forcément le droit/l'envie de modifier... Dans ce cas, c'est le lifetime de la page qui sert à remetre à jour le cache... Un autre concept auquel il faut pensser est la publicité... Si tu dépends d'une régie un peut chiante, tu doit parfois renouveler par toi meme le cache régulièrement (problèmes d'autopromo, de remplissage, de script de pub mal foutu, ...).
*/ Mais quel est l'interret du "daemon pour vider le cache selon divers critères" ? : Je pensse que tu n'as pas compris le fonctionnement de cette nouvelle génération de systèmes de cache. Le client est dirigé automatiquement vers la page statique en cache sans aucune intervention d'aucun script (seul mod_rewrite selon les cas entre en jeu) qui bouferais des ressources à tout casser. Si le serveur ne peut fournir cette page, alors il doit renvoyer une erreur 404. C'est là que toi, tu remplaces l'erreur 404 par ton script ou ton cgi qui vas générer la page dans le cache (le cas échéant, cad si vraiement elle existe hein, sinon il renvoie vraiement un 404) et la renvoyer au client. Donc si le fichier existe dans le cache, meme si il est expiré (parceque certaines contraites te forcent à mettre un délai de vie à certaines pages), comme aucune requète client ne vas déclencher d'execution de script pour cette page, elle ne sera jammais renouvelée. D'où le daemon, ou le script lancé régulièrement par cron (ce qui reviens au meme ;)), qui permet de faire le ménage dans le cache... Ca permet aussi de gérer certains critères bien lourds comme des problèmes d'espace disque... Oui on est sur un serveur, donc oui on met en face les ressources qu'il faut, mais si -pour je ne sait quelle raison- un client veut son cache en tmpfs (mémoire vive), bah 2Go en mémoire vive, ca fait mal :/
*/ pour le problème de savoir si le cache doit etre regénéré au fur et à mesure ou il est invalidé, ou si on efface simplement le ficheir du cache, c'est très complexe... En effet, si tu efface, le premier client qui redemanderas la page se veras servir de facon plus lente que d'habitude (attention, tout est relatif, cad que dans le pire des cas, ca ne seras pas plus lent qu'une page dynamique standart), par contre, pour les pages peut demandées, ca permet d'économiser du disque et de la charge... Par exemple, pour le gros site dont je parlais, le cache représente 4.1Go de html (bon, c'est vrai que certaines pages sont lourdes en HTML parceque mal faites, mais bon, je gère pas les squeletes moi...) pour 210000 pages en cache environ... D'un autre coté si tu le génères en bg, tu t'exposes au fait de générer des pages qui ne seront pas consultées, ou du moins pas avant quelques temps... Donc tu boufes du CPU et du HDD pour rien...
Il faut bien comprendre la signification de ce Bench...
Il ne compare ni les fonctionnalitées, ni la souplesse, ni même les CMS... Il ne compare que les systèmes de caches. Et il permet de noter une très nette différence entre quelques technologies de cache disponibles aujourd'hui.
En effet, je n'ai rien contre Templeet (que j'aprécie), mais c'est plus son cache que le reste qui fait la différence. Et un cache du même type (ie même technologie) aurais significativement les mêmes résultat. Templeet peut donc se féliciter d'avoir un des (sinon le) meilleur systèmes de caches disponibles aujourd'hui...
Je parles en conaissance de cause, j'ai déjas implémenté cette technologie (pages statiques, génération dynamique sur redirect du 404, daemon pour vider le cache selon divers critères) en perl pour différents sites, et la différence est énorme... Le plus impressionnant fut de passer un gros site (plus de hits que LinuxFR) d'un système sans cache (tout le site était géré par un gros script perl de plus de 5500 lignes et des squeletes) où la charge de passait jamais en desous de 8 sur un bi-p3 700MHz 768Mo de ram à un système de cache (quasi-similaire, légèrement adapté à certaines contraintes) où le gros script n'est (quasiement) jamais appellé, ce qui descend la charge à moins de 1 contament sur la même machine (sauf pics dus à diverses opérations externes au site, genre recompil de kernel :D)
PS : pour relativiser le cache il faudrait connaitre le délai de chaque test, le délai d'expiration de la page, MAIS AUSSI le nombre de hits qui expirent la page, car certains systèmes considèrent une page expirée après un certain nombre de hits, ou un certain évènement...
# Re: Samba 3.0 en Release Candidate
Posté par _PinG _ . En réponse à la dépêche Samba 3.0 en Release Candidate. Évalué à 5.
*/ Support Active Directory (w2k, XP, w2k3...)
*/ Support de l'unicode
*/ Réécriture du système d'authentification (notement plus configurable)
*/ Mailleure gestion des erreurs
*/ Meilleure gestion de l'impression
*/ Performances globales améliorées
*/ Migration NT4->Samba facilitée
*/ Gestion des relations d'aprobations avec les DC NT4
*/ Gestion des signatures (w2k3)
*/ Documentation revue
[^] # Re: La calculatrice Google
Posté par _PinG _ . En réponse à la dépêche La calculatrice Google. Évalué à 2.
d'après le maintainer du paquet sur la sid :
Description: Matrix-based scientific software package (a la Matlab and Xmath)
Scilab is a matrix-based scientific software package
resembling Matlab and Xmath. Scilab contains hundreds of
built-in mathematical functions, rich data structures
(including polynomials, rationals,linear systems, lists,
etc...) and comes with a number of specific toolboxes for
control, signal processing, ...
C'est libre d'après les auteurs, mais pas d'après les Debian Guidelines... Mais c'est toujours plus open-source que mathlab ;)
C'est développé par l'inria, donc en plus c'est Francais.
et l'url est là : http://www-rocq.inria.fr/scilab/(...)
[^] # Re: Un moteur de recherche "Open Source" ?
Posté par _PinG _ . En réponse à la dépêche Un moteur de recherche "Open Source" ?. Évalué à 2.
Le tout basé sur un système de réseau de confience par exemple...
Mais les problèmes que je voit sont :
*/ Il faut déjas un bon nombre de nodes au réseau pour stoquer (avec redondance, attention) une DB dans laquelle faire des recherches
*/ Il y a le risque que dans certaines conditions, une recherche n'ai pas accès à la totalitée de la DB, d'où un problème de validité de l'ordre du résultat...
Il faudrait donc des serveurs Internet constament présents, qui stoquent la DB, qui distribuent aux nodes p2p des recherches/parsing à effectuer, qui récoltent les réponses, et qui distribuent aussi à chaque connecté une partie de la DB, afin de répartir les recherches. Mais si une partie de la DB est innacessible, bah on tapes dans la DB des derveurs principaux, ou de leur mirors...
Après, l'aspect réseau de confiance est très important selon moi, ne serai-ce que pour valider les résultats retournés...
[^] # Re: samba 3.0.0-rc1
Posté par _PinG _ . En réponse au journal samba 3.0.0-rc1. Évalué à 1.
[^] # Re: samba 3.0.0-rc1
Posté par _PinG _ . En réponse au journal samba 3.0.0-rc1. Évalué à 1.
*/ Ca doit être quelque chose tout de même :heink:
[^] # Re: J'arrive pas a l'installer ..;
Posté par _PinG _ . En réponse à la dépêche gDesklets, un Karamba-like pour GNOME. Évalué à 1.
Par contre, fait un apt-get update avant, parceque python2.3 n'arrète pas d'être mis à jour dans sid (surtout les modules...).
en résumé :
sudo apt-get update
sudo apt-get install python2.3-gnome2
(et n'oublies pas de faire un upgrade tant que tu y est;) )
# Licences de musique libre > Musique Open Source
Posté par _PinG _ . En réponse à la dépêche Licences de musique libre. Évalué à 1.
[^] # Re: WiFi : La norme g vient d'être ratifiée
Posté par _PinG _ . En réponse à la dépêche WiFi : La norme g vient d'être ratifiée. Évalué à 1.
En même temps si ce sont les couches logicielles limitatives dans le modèle OSI (donc 5 des 7 couches), on n'ateindrait jammais le Gigabit. La limitation ne viens pas du tout d'un ralentissement due aux couches logicielles, du moins pas dans la majorité des cas...
[^] # Re: Mozilla présente Firebird et Thunderbird
Posté par _PinG _ . En réponse à la dépêche Mozilla présente Firebird et Thunderbird. Évalué à 1.
Remarque, vu qu'ils n'ont pas choisit un nom qui correspondait au cahier des charges... Enfin bon...
[^] # Re: Nouvelles du port de Duke3D
Posté par _PinG _ . En réponse au journal Nouvelles du port de Duke3D. Évalué à 1.
[^] # Re: Marre du matériel défaillant
Posté par _PinG _ . En réponse au journal Marre du matériel défaillant. Évalué à 2.
hddtemp -D /dev/tralala
(avec tralala = ton disque)
Regarde si un des champs ne contiens pas une valeure qui pourait être la température (entre 40 et 60° environ selon la disposition et la ventilation...)
[^] # Re: Marre du matériel défaillant
Posté par _PinG _ . En réponse au journal Marre du matériel défaillant. Évalué à 3.
Sinon, mon IBM est à 53° (uptime d'1 semaine, pas spécialement ventillé, asser utilisé car c'est mon /home)
[^] # Re: Marre du matériel défaillant
Posté par _PinG _ . En réponse au journal Marre du matériel défaillant. Évalué à 3.
Sinon il y a peut-être un problme physique à cet endroit du disque... il faudrait essayer de s'arranger pour que ce fichier soit placé à un autre endroit du disque...
# Re: Linux et GPS
Posté par _PinG _ . En réponse au journal Linux et GPS. Évalué à 2.
http://gpsdrive.kraftvoll.at/index.shtml(...)
Bon courage ;)
[^] # Re: Nouvelles du port de Duke3D
Posté par _PinG _ . En réponse au journal Nouvelles du port de Duke3D. Évalué à 1.
[^] # Re: Player mp3 et ogg
Posté par _PinG _ . En réponse au journal Player mp3 et ogg. Évalué à 2.
[^] # Re: yafc : une excellente alternative à sftp et ncftp !
Posté par _PinG _ . En réponse au journal yafc : une excellente alternative à sftp et ncftp !. Évalué à 4.
[^] # Re: Nouvelles du port de Duke3D
Posté par _PinG _ . En réponse au journal Nouvelles du port de Duke3D. Évalué à 1.
# Re: Nouvelles du port de Duke3D
Posté par _PinG _ . En réponse au journal Nouvelles du port de Duke3D. Évalué à 3.
[^] # Re: Euh...
Posté par _PinG _ . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 1.
[^] # 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...
[^] # Re: Euh...
Posté par _PinG _ . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 1.
*/ Je comprendrais jamais pourquoi l'invalidation du cache n'est pas relier à la modification des données qu'il contient : C'est le cas de certains systèmes de cache (templeet par exemple, mais aussi mon système de cache dont je parles dans le post précédent...). Mais certaines données sont volatiles dans la durée, ou selon d'autres critères (nombre d'affichages, ...), c'est le cas -par exemple-d'une page d'accueil de news qui ne présente que les news du jour (Ce que l'on apelle "a la une" ou "édition quotidienne"). De plus, dans certains cas (particuliers), le déploiement du cache est indépendant du code du site, auquel tu n'as pas toujours accès, ou que tu n'as pas forcément le droit/l'envie de modifier... Dans ce cas, c'est le lifetime de la page qui sert à remetre à jour le cache... Un autre concept auquel il faut pensser est la publicité... Si tu dépends d'une régie un peut chiante, tu doit parfois renouveler par toi meme le cache régulièrement (problèmes d'autopromo, de remplissage, de script de pub mal foutu, ...).
*/ Mais quel est l'interret du "daemon pour vider le cache selon divers critères" ? : Je pensse que tu n'as pas compris le fonctionnement de cette nouvelle génération de systèmes de cache. Le client est dirigé automatiquement vers la page statique en cache sans aucune intervention d'aucun script (seul mod_rewrite selon les cas entre en jeu) qui bouferais des ressources à tout casser. Si le serveur ne peut fournir cette page, alors il doit renvoyer une erreur 404. C'est là que toi, tu remplaces l'erreur 404 par ton script ou ton cgi qui vas générer la page dans le cache (le cas échéant, cad si vraiement elle existe hein, sinon il renvoie vraiement un 404) et la renvoyer au client. Donc si le fichier existe dans le cache, meme si il est expiré (parceque certaines contraites te forcent à mettre un délai de vie à certaines pages), comme aucune requète client ne vas déclencher d'execution de script pour cette page, elle ne sera jammais renouvelée. D'où le daemon, ou le script lancé régulièrement par cron (ce qui reviens au meme ;)), qui permet de faire le ménage dans le cache... Ca permet aussi de gérer certains critères bien lourds comme des problèmes d'espace disque... Oui on est sur un serveur, donc oui on met en face les ressources qu'il faut, mais si -pour je ne sait quelle raison- un client veut son cache en tmpfs (mémoire vive), bah 2Go en mémoire vive, ca fait mal :/
*/ pour le problème de savoir si le cache doit etre regénéré au fur et à mesure ou il est invalidé, ou si on efface simplement le ficheir du cache, c'est très complexe... En effet, si tu efface, le premier client qui redemanderas la page se veras servir de facon plus lente que d'habitude (attention, tout est relatif, cad que dans le pire des cas, ca ne seras pas plus lent qu'une page dynamique standart), par contre, pour les pages peut demandées, ca permet d'économiser du disque et de la charge... Par exemple, pour le gros site dont je parlais, le cache représente 4.1Go de html (bon, c'est vrai que certaines pages sont lourdes en HTML parceque mal faites, mais bon, je gère pas les squeletes moi...) pour 210000 pages en cache environ... D'un autre coté si tu le génères en bg, tu t'exposes au fait de générer des pages qui ne seront pas consultées, ou du moins pas avant quelques temps... Donc tu boufes du CPU et du HDD pour rien...
# Attetion au piège!
Posté par _PinG _ . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 4.
Il ne compare ni les fonctionnalitées, ni la souplesse, ni même les CMS... Il ne compare que les systèmes de caches. Et il permet de noter une très nette différence entre quelques technologies de cache disponibles aujourd'hui.
En effet, je n'ai rien contre Templeet (que j'aprécie), mais c'est plus son cache que le reste qui fait la différence. Et un cache du même type (ie même technologie) aurais significativement les mêmes résultat. Templeet peut donc se féliciter d'avoir un des (sinon le) meilleur systèmes de caches disponibles aujourd'hui...
Je parles en conaissance de cause, j'ai déjas implémenté cette technologie (pages statiques, génération dynamique sur redirect du 404, daemon pour vider le cache selon divers critères) en perl pour différents sites, et la différence est énorme... Le plus impressionnant fut de passer un gros site (plus de hits que LinuxFR) d'un système sans cache (tout le site était géré par un gros script perl de plus de 5500 lignes et des squeletes) où la charge de passait jamais en desous de 8 sur un bi-p3 700MHz 768Mo de ram à un système de cache (quasi-similaire, légèrement adapté à certaines contraintes) où le gros script n'est (quasiement) jamais appellé, ce qui descend la charge à moins de 1 contament sur la même machine (sauf pics dus à diverses opérations externes au site, genre recompil de kernel :D)
PS : pour relativiser le cache il faudrait connaitre le délai de chaque test, le délai d'expiration de la page, MAIS AUSSI le nombre de hits qui expirent la page, car certains systèmes considèrent une page expirée après un certain nombre de hits, ou un certain évènement...
[^] # Re: Mozilla 1.4 Alpha (mais où s'arrêteront-ils ?)
Posté par _PinG _ . En réponse à la dépêche Mozilla 1.4 Alpha (mais où s'arrêteront-ils ?). Évalué à 1.
[^] # Re: Mozilla 1.4 Alpha (mais où s'arrêteront-ils ?)
Posté par _PinG _ . En réponse à la dépêche Mozilla 1.4 Alpha (mais où s'arrêteront-ils ?). Évalué à 4.
Et c'est interessant, parceque franchement, quand je scroll sous moz, j'ai le mal de mer :/