l'interet d'en faire une lib, c'est que cela peut fournir les fonctions de bases au plus grand nombre. Après, l'interfacer avec dbus & co, sera un plus.
faire une libcameleon qui propose des fonctions tel que :
change_format( source, dest, MIME_type );
open_as( file, MIME_type );
apres, cameleon ne deviendra que l'interface graphique pour utiliser la lib.
des commandes pour la ligne de commande seront facilement faisable.
surtout, cela serait le bonheur pour plein de softs :D puisqu'il faudra juste que la libcameleon supporte un noveau format pour que tous les softs dependant de la libcameleon le supporte automatiquement :D
vu la faible participation au concours alors qu'un bon laps de temps a été laissé, et vu que certaines personnes ont déjà exprimé ici, le fait qu'ils ne lisaient pas ( ou plus ) les depeches, il est plausible de penser que certaines personnes n'étaient pas au courant.
le but de ce journal est d'identifier ceux qui n'étaient pas au courant et ceux qui auraient voulu y participer pour pouvoir dorénavant savoir si cela a un sens de faire un multipostage ( ou crosspost ) ou pas.
ce n'est pas la premiere erreur de conception du à une mauvaise conscience de la scalabilité ... ni la derniere ...
Je n'utilise le noatime que dans certains contextes.
Et sinon, je fais comment pour disposer de nom de fichiers de plus de 255 caractères ?
Plus court ? non.
Une BDD genre MYSQL ? et tant qu'à faire du TOMCAT/JBOSS ?
SQLite ? beurk.
BDB & co ? pourquoi pas ... mais niveau maintenabilité ca pue un peu.
si quelqu'un a une solution autre, je suis preneuse :)
la méta donnée est une donnée non ? si on applique la pensée unixienne " tout est fichier " ... les méta données devrait être un fichier en tant que tel non ? passons le troll sur la philosophie unixienne ;)
tu parles des SGBDR, pour ce qui est du pourquoi de ta question, la réponse est double :
- tu n'indexes que ce que tu sais devoir rechercher tôt ou tard
- tu n'indexes que ce que tu ne mets pas à jour trop fréquemment
Et sur ce coup, les index au niveau des SGBDR est juste un contournement lié aux performances catastrophiques du modèle relationnelle.
Le modèle relationnel est est bien pour rechercher des informations, pas pour naviguer dans l'information ( la nuance est subtile et l'aparté serait trop longue à développer. Entre autre, Codd & Date sont de saines lectures sur le sujet ).
Et ta comparaison avec les index ne sert a rien puisque les index sont accessoires, et sont des doublons reconstructibles des données déjà existantes.
pour ce qui est de la FS, quelque soit la taille des méta données, elles auront toujours une taille moindre par rapport aux données. Donc leur écriture sera toujours plus rapide. et quand on modifie un fichier, on ne modifie pas à chaque fois les méta données et encore moins l'ensemble des méta données.
Il y a une limite a ne pas oublier : c'est qu'un file system doit assurer l'intégrité des données qu'il doit stocker, or un secteur de disque dur (encore pour un bon moment la reference du stockage commun) fait 512 octets, pas plus.
Si tu commence a répartir tes inodes (la structure qui reference un objet dans un file system) sur plusieurs secteurs, qu'est ce qui te garantit que l ón ne va pas couper l'electricité entre 2 secteurs concernant tes grosses inodes ? alors qu'un secteur s'écrit en une seule fois par le controleur du disque, sans risque de ce genre.
Donc on ne dispose pas de plus de 512 octets pour decrire un fichier dans le file system, et on a pas que son nom a conserver, mais aussi les differentes dates, id, droits, type, proprietaire ...
donc 255 ou 256, 'est deja pas si mal, ou alors il faut reinventer les disques durs avec des plus gros secteurs, mais on va tout casser. compatibilité quand tu nous tiens ...
c'est d'ailleurs pour la même raison que tu as que des fichiers de 512 octets sur ton disque ?
parce que qui te dit que tu ne vas pas avoir de problème électrique au moment où tu seras en train d'écrire ton fichier ?
et tu utilises aussi l'algo de I2BP pour assurer une tres bonne qualité de la zik que tu as sur ton disque, et ce, en 512 octets ?
si le problème n'existe pas pour un contenu de fichier, pourquoi existerait il pour un nom ? au pire, ca fini dans lost+found comme tous les blocs qui ont un problème du fait d'une coupure au mauvais moment.
non ?
tu n'as pas le sentiment d'etre hors sujet ? windows est répandu car il y a vente forcée à l'achat du PC.
quand j'achete une platine CD ( ou autre ), on ne me refourgue pas l'intégral des lives de la star ac, le roi lion, les 10 commandements, et les inédits de Céline Dion et Benjamin Biolay !
Quand, je vais acheter du DJ Shadow, du Mogwai, du Massive Attack, du UNKLE, du Iggy Pop, du Rinocérose, du Tori Amos, du PJ Harvey, du Oi Va Voi, du Piazolla, du Chemical Brothers, ... c'est que j'ai envie de les acheter eux.
Si personne ne voulait acheter de ce qui est vendu, les majors ne gagneraient rien ... sauf à faire de la vente liée à l'achat de lecteur CD/MP3 & co.
J'ai du mal à voir du matraquage publicitaire pour nombre d'artistes de ma playlist ... je n'écoute que France Culture comme radio. Je ne dis pas que cela n'existe pas, je dis juste que si tu as le contenu que tu veux quand tu écoutes la radio ( genre skyrock & co ) ou quand tu choisi de regarder la graine de nouvelle popstar et la starac.
je n'y suis pour rien :D
mais en gros, j'aurais fait exactement la meme chose, j'en aurais fait certainement plus pour ne pas avoir une fausse redondance en frontal.
Intégrer Gitoyen représente un coût non négligeable. On revient encore une fois au problème du ticket d'entrée.
Je ne vois pas Toile Libre dans les membres du Gitoyen, et sur le site de toile libre, il est dit qu'ils sont en train de rejoindre Gitoyen.
Il y aura mutualisation dans une certaine mesure à ce moment là :)
tu peux desactiver tout au niveau PHP, mais à un moment, il ne restera que "echo" car meme mysql_connect devra etre restreint.
donc quota disque, quota CPU ( au fait le SIGXCPU est géré correctement par combien de soft ? ), le monitoring de charge par client ( donc attention à ne pas se tromper dans la detection ), les quotas noyau pour le cpu depuis les 2.6.24 me semble t il, les quotas traffic entrant et traffic sortant, filtrage d'opcode ... tu n'as pas le sentiment qu'à un moment à trop vouloir tout réguler tes machines ne feront que ca ?
pour ce qui est du poste chez youporn, merci pour l'info :)
mais c'est quoi cette manie de répondre à un propos qui n'est pas une généralisation par une cas particulier ?
je peux aussi parler de mes machines persos ... ca ne changera rien.
dans le même esprit, tu peux avoir des super mots de passe appris par coeur, il n'empeche en rien que ce qui suit est ce que constate l'auteur du blog : http://zythom.blogspot.com/2009/04/dechiffrage.html
Relis bien, je ne généralise pas.
pour ce qui est de apache, tu parles d'un gain de 20% ...
cela signifie quoi d'un point de vue conso électrique ?
à conso électrique égale, ton lighttpd sort 20% de pages en plus. donc apache pollue plus puisqu'à volume traffic équivalent le nombre de machine apache pour tenir la charge sera supérieur ou égale à un lighttpd.
sinon c'est cool ta machine qui consomme moins de 10W te suffit ... mais combien de personnes paient une machine surdimensionnée chez OVH ou dédibox pour faire la meme chose ?
Mon propos ne visent pas ceux qui adaptent au plus juste leur materiel et leur soft à leur besoin.
Je parle de certaines pratiques courantes et certains softs courants et qui sont globalement polluante.
un dev recyclé en fin de vie du projet en petite galette verte pleine de protéine auquel on ajoutera pour séduire le geek, de la sauce tomate de la mozzarella et d'autres ingrédients.
1Go de disque c'est largement suffisant pour poser pas mal soucis.
avec 1Go, tu ne livres pas ton contenu vendable ( souvent tu n'en as pas mais tu est affilié ), mais tu colles sans soucis la partie présentation de ta ferme de sites X.
Tu n'as pas de photos non plus ( d'un autre coté, tout ca est chez ton fournisseur de contenus ), juste du code PHP, de la skin et quelques caches de flux XML pour savoir quel contenu est dispo chez quel fournisseur.
Pour un flickr ou un youtube, tu colles ton code ( le truc qui bouffe du CPU ) dans ton 1 Go, et pour le reste, tu livres avec du Amazon S3 ( et parce que tu n'es pas finaud ou tu es vil, ton code PHP fait office de proxy à la livraison depuis le S3 dans l'esprit echo @file( ); ).
Pour le mirroir WP, on est pas loin non plus de la meme stratégie ...
je te concede pour le le coup du pool NNTP, et des mirroirs de distribs ( quoi que juste en HTTP, on revient encore aux fondamentaux précédents ).
tu sous-entends dans ton premier commentaire que les techno open source pour le web ne tienne la charge qu'au prix d'effort couteux,
toi, tu as du mal avec le francais ...
j'ai dit "quand on voit certains web softs libres, je n'ai pas dit "tous les web softs libres" ... pourquoi pas tous ? parce qu'il existe des outils bien faits :P
j'ai dit "je ne dis pas que c'est mieux du coté des softs proprio, je ne le pense pas." cela signifie que libre et proprio même merdier cela ne signifie pas " le libre c'est plus pourri que le proprio ".
j'ai dit "non, ce n'est pas un probleme de langage, ni de techno, c'est un problème d'ignorance de certains sujets par les devs d'appli" je vois mal où je parle de PHP.
Tu parles de la lourdeur de JBoss, sincèrement, est ce pertinent d'avoir un équivalent de dotclear en JBoss pour quelques dizaines de milliers de pages vues par mois ?
penses tu qu'à infra égale Wikimedia aurait intérêt à passer sur du JBoss ?
les skyblog peut etre en JBoss ?
ca ne t'intrigue pas la différence de temps de réponse entre http://xwiki.org/ et http://mediawiki.org/ ?
Pour ce qui est de la tenue de charge autrement qu'avec un reverse proxy, oui, je sais, il existe des solutions ...
mais après avoir optimisé la FS, collé un cache d'opcode pour PHP ( python et perl ont des alternatives ), torturé MySQL/PostGreSQL, utilisé à fond la tmpfs, torturé apache ( ou autre ), il y a un moment où le problème s'appelle le code de l'appli web ( et ce, quelque soit le langage ).
Question bête :
ton drupal, il encaisse quoi comme trafic sur quelle config ?
je viens de chercher quelques benchmarks sur drupal :
- http://buytaert.net/drupal-5-performance ( 250 r/s théorique avec un test pratique de 20 r/s - et vu que le -c 250 n'a pas été testé avec ab2 , la version importe peu )
- http://drupal.org/node/79237 ( -c 1 le test ! pour un resultat de 2,7 r/s théorique ! ca c'est de la tenue de charge ... surtout quand on voit que ca commence à cafouiller dès le dernier décile pour froler un temps de réponse proche du double ... sur un total de 100 requetes sur la meme page ).
Tu testes la plupart de softs de type blog, wiki, CMS et tu verras que ca ne tiens pas réellement un minimum de charge sans un reverse proxy en frontal.
Sinon tu peux aussi regarder apache qui si il est très riche est un polluant pour tout ce qui est contenu statique ... un lighttpd ( ou thttpd ) tenant plus de requetes/seconde consomme au final moins par requete sur du contenu statique.
pour ce qui est du web, tu peux déjà dégrossir tes benchmarks avec ab ( bien qu'il soit trop sommaire pour faire un benchmark correct ). ab du fait qu'il teste qu'une seule URL a le mérite de réduire l'impact hardware au minimum puisque tout ce qui est cachable au niveau noyau et applicatif le sera si c'est bien codé.
Apres utiliser un postfix ( ou autre ) simplement pour écouter sur 127.0.0.1 et renvoyer sur un hub me parait " tres couteux ".
Après, cette manie de prendre des dédiés pour livrer des volumes risibles tant en mail qu'en contenu web, et ce, souvent juste pour le plaisir d'avoir son serveur est me semble t il, une belle source de pollution énergétique.
# une dépeche ?
Posté par Mouns (site web personnel) . En réponse au journal Salon Logiciels et Oeuvres Libres près de Rennes 27 sept 2009. Évalué à 2.
[^] # Re: suggestion pour plus tard
Posté par Mouns (site web personnel) . En réponse à la dépêche Premières versions de Caméléon et Final Page. Évalué à 6.
# suggestion pour plus tard
Posté par Mouns (site web personnel) . En réponse à la dépêche Premières versions de Caméléon et Final Page. Évalué à 5.
change_format( source, dest, MIME_type );
open_as( file, MIME_type );
apres, cameleon ne deviendra que l'interface graphique pour utiliser la lib.
des commandes pour la ligne de commande seront facilement faisable.
surtout, cela serait le bonheur pour plein de softs :D puisqu'il faudra juste que la libcameleon supporte un noveau format pour que tous les softs dependant de la libcameleon le supporte automatiquement :D
[^] # Re: Place d'Hasard par rapport à GSL, OpenSSL & cie
Posté par Mouns (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 2.
[^] # Re: Place d'Hasard par rapport à GSL, OpenSSL & cie
Posté par Mouns (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 2.
[^] # Re: Place d'Hasard par rapport à GSL, OpenSSL & cie
Posté par Mouns (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 3.
[^] # Re: Et aussi
Posté par Mouns (site web personnel) . En réponse au journal Résultat du concours linuxfr. Évalué à 2.
vu la faible participation au concours alors qu'un bon laps de temps a été laissé, et vu que certaines personnes ont déjà exprimé ici, le fait qu'ils ne lisaient pas ( ou plus ) les depeches, il est plausible de penser que certaines personnes n'étaient pas au courant.
le but de ce journal est d'identifier ceux qui n'étaient pas au courant et ceux qui auraient voulu y participer pour pouvoir dorénavant savoir si cela a un sens de faire un multipostage ( ou crosspost ) ou pas.
[^] # Re: Place d'Hasard par rapport à GSL, OpenSSL & cie
Posté par Mouns (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 2.
parce que cela me semble plutot interessant comme soft :)
faudrait aussi faire des binding python/perl/php & co ... yaka fokon ;)
[^] # Re: Place d'Hasard par rapport à GSL, OpenSSL & cie
Posté par Mouns (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 1.
parce que cela me semble plutot interessant comme soft :)
faudrait aussi faire des binding python/perl/php & co ... yaka fokon ;)
[^] # Re: structure des disques
Posté par Mouns (site web personnel) . En réponse au journal personne n'aura besoin de plus de 640ko de RAM. Évalué à 2.
Je n'utilise le noatime que dans certains contextes.
Et sinon, je fais comment pour disposer de nom de fichiers de plus de 255 caractères ?
Plus court ? non.
Une BDD genre MYSQL ? et tant qu'à faire du TOMCAT/JBOSS ?
SQLite ? beurk.
BDB & co ? pourquoi pas ... mais niveau maintenabilité ca pue un peu.
si quelqu'un a une solution autre, je suis preneuse :)
[^] # Re: structure des disques
Posté par Mouns (site web personnel) . En réponse au journal personne n'aura besoin de plus de 640ko de RAM. Évalué à 2.
c'est tres utile sur des serveurs qui chargent un peu trop ...
[^] # Re: structure des disques
Posté par Mouns (site web personnel) . En réponse au journal personne n'aura besoin de plus de 640ko de RAM. Évalué à 1.
tu parles des SGBDR, pour ce qui est du pourquoi de ta question, la réponse est double :
- tu n'indexes que ce que tu sais devoir rechercher tôt ou tard
- tu n'indexes que ce que tu ne mets pas à jour trop fréquemment
Et sur ce coup, les index au niveau des SGBDR est juste un contournement lié aux performances catastrophiques du modèle relationnelle.
Le modèle relationnel est est bien pour rechercher des informations, pas pour naviguer dans l'information ( la nuance est subtile et l'aparté serait trop longue à développer. Entre autre, Codd & Date sont de saines lectures sur le sujet ).
Et ta comparaison avec les index ne sert a rien puisque les index sont accessoires, et sont des doublons reconstructibles des données déjà existantes.
pour ce qui est de la FS, quelque soit la taille des méta données, elles auront toujours une taille moindre par rapport aux données. Donc leur écriture sera toujours plus rapide. et quand on modifie un fichier, on ne modifie pas à chaque fois les méta données et encore moins l'ensemble des méta données.
[^] # Re: structure des disques
Posté par Mouns (site web personnel) . En réponse au journal personne n'aura besoin de plus de 640ko de RAM. Évalué à 0.
Si tu commence a répartir tes inodes (la structure qui reference un objet dans un file system) sur plusieurs secteurs, qu'est ce qui te garantit que l ón ne va pas couper l'electricité entre 2 secteurs concernant tes grosses inodes ? alors qu'un secteur s'écrit en une seule fois par le controleur du disque, sans risque de ce genre.
Donc on ne dispose pas de plus de 512 octets pour decrire un fichier dans le file system, et on a pas que son nom a conserver, mais aussi les differentes dates, id, droits, type, proprietaire ...
donc 255 ou 256, 'est deja pas si mal, ou alors il faut reinventer les disques durs avec des plus gros secteurs, mais on va tout casser. compatibilité quand tu nous tiens ...
c'est d'ailleurs pour la même raison que tu as que des fichiers de 512 octets sur ton disque ?
parce que qui te dit que tu ne vas pas avoir de problème électrique au moment où tu seras en train d'écrire ton fichier ?
et tu utilises aussi l'algo de I2BP pour assurer une tres bonne qualité de la zik que tu as sur ton disque, et ce, en 512 octets ?
si le problème n'existe pas pour un contenu de fichier, pourquoi existerait il pour un nom ? au pire, ca fini dans lost+found comme tous les blocs qui ont un problème du fait d'une coupure au mauvais moment.
non ?
[^] # Re: Aucun rapport
Posté par Mouns (site web personnel) . En réponse au journal personne n'aura besoin de plus de 640ko de RAM. Évalué à 1.
[^] # Re: Confusion des genres
Posté par Mouns (site web personnel) . En réponse au journal HADOPI "Si [les études (...)] disaient vrai, le marché du disque canadien aurait été multiplié par trois ces dernières années.". Évalué à 2.
ce qui, je pense contre balance et compense allègrement mon goût pour France Culture :D
[^] # Re: Confusion des genres
Posté par Mouns (site web personnel) . En réponse au journal HADOPI "Si [les études (...)] disaient vrai, le marché du disque canadien aurait été multiplié par trois ces dernières années.". Évalué à 6.
2. J'essuie l'interieur de la casserole que je viens de laver, pour la remplir d'eau pour cuire des pâtes.
Donc oui, au final, je suis dans la moyenne :P
[^] # Re: Confusion des genres
Posté par Mouns (site web personnel) . En réponse au journal HADOPI "Si [les études (...)] disaient vrai, le marché du disque canadien aurait été multiplié par trois ces dernières années.". Évalué à 2.
quand j'achete une platine CD ( ou autre ), on ne me refourgue pas l'intégral des lives de la star ac, le roi lion, les 10 commandements, et les inédits de Céline Dion et Benjamin Biolay !
Quand, je vais acheter du DJ Shadow, du Mogwai, du Massive Attack, du UNKLE, du Iggy Pop, du Rinocérose, du Tori Amos, du PJ Harvey, du Oi Va Voi, du Piazolla, du Chemical Brothers, ... c'est que j'ai envie de les acheter eux.
Si personne ne voulait acheter de ce qui est vendu, les majors ne gagneraient rien ... sauf à faire de la vente liée à l'achat de lecteur CD/MP3 & co.
J'ai du mal à voir du matraquage publicitaire pour nombre d'artistes de ma playlist ... je n'écoute que France Culture comme radio. Je ne dis pas que cela n'existe pas, je dis juste que si tu as le contenu que tu veux quand tu écoutes la radio ( genre skyrock & co ) ou quand tu choisi de regarder la graine de nouvelle popstar et la starac.
[^] # Re: Confusion des genres
Posté par Mouns (site web personnel) . En réponse au journal HADOPI "Si [les études (...)] disaient vrai, le marché du disque canadien aurait été multiplié par trois ces dernières années.". Évalué à 4.
ben merde :(
[^] # Re: heu ...
Posté par Mouns (site web personnel) . En réponse au journal Logiciels Libres & Developpement durable. Évalué à 2.
je n'y suis pour rien :D
mais en gros, j'aurais fait exactement la meme chose, j'en aurais fait certainement plus pour ne pas avoir une fausse redondance en frontal.
[^] # Re: comment couler le projet
Posté par Mouns (site web personnel) . En réponse au journal Nouvelles de toile libre, l'hébergeur à prix libre .. Évalué à 2.
Je ne vois pas Toile Libre dans les membres du Gitoyen, et sur le site de toile libre, il est dit qu'ils sont en train de rejoindre Gitoyen.
Il y aura mutualisation dans une certaine mesure à ce moment là :)
tu peux desactiver tout au niveau PHP, mais à un moment, il ne restera que "echo" car meme mysql_connect devra etre restreint.
donc quota disque, quota CPU ( au fait le SIGXCPU est géré correctement par combien de soft ? ), le monitoring de charge par client ( donc attention à ne pas se tromper dans la detection ), les quotas noyau pour le cpu depuis les 2.6.24 me semble t il, les quotas traffic entrant et traffic sortant, filtrage d'opcode ... tu n'as pas le sentiment qu'à un moment à trop vouloir tout réguler tes machines ne feront que ca ?
pour ce qui est du poste chez youporn, merci pour l'info :)
[^] # Re: heu ...
Posté par Mouns (site web personnel) . En réponse au journal Logiciels Libres & Developpement durable. Évalué à 2.
je peux aussi parler de mes machines persos ... ca ne changera rien.
dans le même esprit, tu peux avoir des super mots de passe appris par coeur, il n'empeche en rien que ce qui suit est ce que constate l'auteur du blog : http://zythom.blogspot.com/2009/04/dechiffrage.html
Relis bien, je ne généralise pas.
pour ce qui est de apache, tu parles d'un gain de 20% ...
cela signifie quoi d'un point de vue conso électrique ?
à conso électrique égale, ton lighttpd sort 20% de pages en plus. donc apache pollue plus puisqu'à volume traffic équivalent le nombre de machine apache pour tenir la charge sera supérieur ou égale à un lighttpd.
sinon c'est cool ta machine qui consomme moins de 10W te suffit ... mais combien de personnes paient une machine surdimensionnée chez OVH ou dédibox pour faire la meme chose ?
Mon propos ne visent pas ceux qui adaptent au plus juste leur materiel et leur soft à leur besoin.
Je parle de certaines pratiques courantes et certains softs courants et qui sont globalement polluante.
[^] # Re: Développement durable ?
Posté par Mouns (site web personnel) . En réponse au journal Logiciels Libres & Developpement durable. Évalué à 3.
un dev recyclé en fin de vie du projet en petite galette verte pleine de protéine auquel on ajoutera pour séduire le geek, de la sauce tomate de la mozzarella et d'autres ingrédients.
[^] # Re: comment couler le projet
Posté par Mouns (site web personnel) . En réponse au journal Nouvelles de toile libre, l'hébergeur à prix libre .. Évalué à 2.
1Go de disque c'est largement suffisant pour poser pas mal soucis.
avec 1Go, tu ne livres pas ton contenu vendable ( souvent tu n'en as pas mais tu est affilié ), mais tu colles sans soucis la partie présentation de ta ferme de sites X.
Tu n'as pas de photos non plus ( d'un autre coté, tout ca est chez ton fournisseur de contenus ), juste du code PHP, de la skin et quelques caches de flux XML pour savoir quel contenu est dispo chez quel fournisseur.
Pour un flickr ou un youtube, tu colles ton code ( le truc qui bouffe du CPU ) dans ton 1 Go, et pour le reste, tu livres avec du Amazon S3 ( et parce que tu n'es pas finaud ou tu es vil, ton code PHP fait office de proxy à la livraison depuis le S3 dans l'esprit echo @file( ); ).
Pour le mirroir WP, on est pas loin non plus de la meme stratégie ...
je te concede pour le le coup du pool NNTP, et des mirroirs de distribs ( quoi que juste en HTTP, on revient encore aux fondamentaux précédents ).
[^] # Re: heu ...
Posté par Mouns (site web personnel) . En réponse au journal Logiciels Libres & Developpement durable. Évalué à 1.
tu sous-entends dans ton premier commentaire que les techno open source pour le web ne tienne la charge qu'au prix d'effort couteux,
toi, tu as du mal avec le francais ...
j'ai dit "quand on voit certains web softs libres, je n'ai pas dit "tous les web softs libres" ... pourquoi pas tous ? parce qu'il existe des outils bien faits :P
j'ai dit "je ne dis pas que c'est mieux du coté des softs proprio, je ne le pense pas." cela signifie que libre et proprio même merdier cela ne signifie pas " le libre c'est plus pourri que le proprio ".
j'ai dit "non, ce n'est pas un probleme de langage, ni de techno, c'est un problème d'ignorance de certains sujets par les devs d'appli" je vois mal où je parle de PHP.
Tu parles de la lourdeur de JBoss, sincèrement, est ce pertinent d'avoir un équivalent de dotclear en JBoss pour quelques dizaines de milliers de pages vues par mois ?
penses tu qu'à infra égale Wikimedia aurait intérêt à passer sur du JBoss ?
les skyblog peut etre en JBoss ?
ca ne t'intrigue pas la différence de temps de réponse entre http://xwiki.org/ et http://mediawiki.org/ ?
Pour ce qui est de la tenue de charge autrement qu'avec un reverse proxy, oui, je sais, il existe des solutions ...
mais après avoir optimisé la FS, collé un cache d'opcode pour PHP ( python et perl ont des alternatives ), torturé MySQL/PostGreSQL, utilisé à fond la tmpfs, torturé apache ( ou autre ), il y a un moment où le problème s'appelle le code de l'appli web ( et ce, quelque soit le langage ).
Question bête :
ton drupal, il encaisse quoi comme trafic sur quelle config ?
je viens de chercher quelques benchmarks sur drupal :
- http://buytaert.net/drupal-5-performance ( 250 r/s théorique avec un test pratique de 20 r/s - et vu que le -c 250 n'a pas été testé avec ab2 , la version importe peu )
- http://drupal.org/node/79237 ( -c 1 le test ! pour un resultat de 2,7 r/s théorique ! ca c'est de la tenue de charge ... surtout quand on voit que ca commence à cafouiller dès le dernier décile pour froler un temps de réponse proche du double ... sur un total de 100 requetes sur la meme page ).
[^] # Re: heu ...
Posté par Mouns (site web personnel) . En réponse au journal Logiciels Libres & Developpement durable. Évalué à 4.
Sinon tu peux aussi regarder apache qui si il est très riche est un polluant pour tout ce qui est contenu statique ... un lighttpd ( ou thttpd ) tenant plus de requetes/seconde consomme au final moins par requete sur du contenu statique.
pour ce qui est du web, tu peux déjà dégrossir tes benchmarks avec ab ( bien qu'il soit trop sommaire pour faire un benchmark correct ). ab du fait qu'il teste qu'une seule URL a le mérite de réduire l'impact hardware au minimum puisque tout ce qui est cachable au niveau noyau et applicatif le sera si c'est bien codé.
Apres utiliser un postfix ( ou autre ) simplement pour écouter sur 127.0.0.1 et renvoyer sur un hub me parait " tres couteux ".
Après, cette manie de prendre des dédiés pour livrer des volumes risibles tant en mail qu'en contenu web, et ce, souvent juste pour le plaisir d'avoir son serveur est me semble t il, une belle source de pollution énergétique.