Reprise du message précédent :
Bah je sais pas moi, je me demandais ce qui pouvait les intéresser

 
Ben, le copy on write, dans le principe, il n'y a rien de plus simple. Il suffit de dupliquer les données avant de les modifier (et de faire les modifs sur la copie, bien évidemment). Après, on peut faire un système plus évolué afin de déterminer quand il est nécessaire de faire cette copie et quand ce n'est pas le cas, mais ça implique de se faire chier avec de la synchronisation.
 
Pour le cache, c'est assez simple. Si on fait ça avec de la shared, il faut se coder un allocateur qui va retourner des offsets mémoire relatifs à l'adresse du segment de shared (implémenter l'allocateur est la seule difficulté sérieuse). Ensuite, il faut allouer les données en cache en passant via cet allocateur. On se récupère un offset qu'il faut convertir en adresse mémoire. Ce travail (conversion offset vers adresse) est à faire en permanence. En plus clair, on n'utilise plus directement des pointeurs mais des offsets à partir desquels on déduit les pointeurs. Le coût d'un tel système réside au niveau de l'allocation et de cette indirection supplémentaire. La limite est au niveau de cette unique segment de shared (c'est un peu chiant d'en utiliser plusieurs) qu'on ne peut pas réallouer simplement et efficacement. La complexité réside au niveau de l'allocateur et de la cohérence entre le cache et le sgbd (travail en double). Par contre, le gain est énorme (pas de com réseau, pas d'IO disque, pas de cpu utilisée pour récupérer toujours les mêmes données, ...).

 
Cher Docteur Maboule.
Tout d'abord j'ai hier parcouru rapidement ce topic (essentiellement les vieux messages) et je dois dire que j'ai particulierement apprécié vos interventions (surtout votre fake de fake). Je trouve votre acharnement à vouloir produire un forum totalement optimisé tout à fait rafraichissant et plaisant dans ce monde de design pattern et d'UML.  
 
Pour en revenir à votre question, je n'ai jamais lu le code d'apache, mais j'en connais l'architecture et j'ai pu comparer ses perfs à d'autres server (je parle de pages statiques uniquement).
IIS, pour ne pas le citer, se montre déjà bien plus véloce, et d'autres gros server commerciaux comme Zeus sont encore bien plsu rapide.
Pour vous donner une idée allez faire un tour sur les score de bench SPECweb99:
http://www.spec.org/web99/results/
 
Les server testés tournent rarement sous Apache. J'ai pu voir Apache sortir un score d'environ 200 (200 client simultannées avec une qualité de service donnée) sur un PIII 1ghz alors que IIS avait un score plus que doubles, et que des machins genre TUX sortaient des score de 1000.
 
Le probleme d'apache c'est sa conception totalement multithread: il pré-fork un pool de process (ou de thread dans les derniere versions, mais la situation est exactement identique mis à part le passage des descripteurs de fichier d'un thread à l'autre qui est plus simple dans ce cas, mais les perfs sont quasi identiques) et ecoute les connexions sur son thread principale, puis les balance aux autres thread (passage de fd). Il est donc tres consommateur en ressources memoire et CPU (meme si ca marche mieux avec le scheduleur en O(1) de linux 2.6) et se montre incapable de gerer un tres grand nombre de connexions simultannées puisque celles ci implique egalement un grand nombre d'immondes threads.
Zeus au contraire ainsi que d'autres fonctionnent sur un principe bien different: le thread principale gere l'ensemble des connexions avec des mecanismes de notification (epoll, kqueue, etc...) et ne recour à d'autre thread (ou process pre forkés) que pour les acces synchrones (acces disques si l'OS n'a pas d'AIO, acces base de donnée si il y a lieu) et les CGI et autres.
 
voila un lien interessant à ce sujet: (le site entier est ineressant, et sa dietlibc pourrait d'ailleurs vous interesser)
http://bulk.fefe.de/scalable-networking.pdf
 
et bien sur la bine connue page c10k qui resume bien les differentes approches:
http://www.kegel.com/c10k.html
 
 
maintenant, quand on parle de pages dynamiques le probleme est sans doute un peu different (mais pas forcement)

 
Permettez moi d'objecter.
Pour moi le copy on write consiste justement à eviter de copier des donnée tant que celles ci sont identique. Elle ne sont copiée que si elle se trouve modifiées (on write donc).
 
c'est le principe qu'utilisent la plupart des OS pour implementer le fork: l'espace memoire est partagé entre les deux process pour ce qui est de la lecture, mais des que l'un des process tente d'ecrire, la page memoire est dupliquée pour pouvoir etre mdoifiée.
 
C'est ce qui permet à apache de gerer un grand nombre de process d'un meme interpreteur (Perl ou PHP) sans pour autant avoir besoin  de n fois l'espace memoire: seules les données différentes sont dupliquées et les librairies sont toalement partagées.

 
Tres intéressant ton post, merci!  
 
Tu connais mieux qu'Apache2 en opensource ?

Ptain sa cause super technique ici  

même si je n'en pige pas le quart, je trouve qu'il y a là-dedans quelque chose d'étonnament esthétique

Un serveur web qui gère toutes les connexions sur le même thread ça me parait bizarre...c'est typiquement le style d'applis ou le multithread parait intéressant...
Il se passe quoi sur ce genre de soft quand on passe sur une machine multiprocesseurs?

 
en open source je sais pas.
Pour servir des fichier statiques tu a toujorus TUX.
La plupart de ces serveurs "de competition" open source (genre gatling, TUX, flash etc.) se contentent souvent de faire du CGI ou du fastCGI et n'ont pas de modules specialisé pour perl, php, python, etc.

 
De toutes facons tu est presque obligé d'avoir des thread pour les acces disques (qui sont presques toujours bloquant) et aussi pour tes pages dynamiques. Mais le tout est de ne pas en avoir trop pour eviter de bouffer la RAM et aussi les changement de contexte permanant (passage d'une thread à l'autre) qui sont assez couteux en ressources.

En plus, il y a plein de déclinaison d'apache2, je présumes que chacune ont leurs avantage inconvéniant...  (perchild, prefork, threadpool, worker)

quid de thttpd pour le statique ?

j'ai été tres dessus par thttpd: il ne gere pas le keep alive! (ou alors j'ai merdé, mais il me semble bien). Du coup il a beau se debattre comme il veut il est forcement à la ramasse.
D'apres ce que j'ai pu voir ou tester TUX est vraiment pas mauvais et gatling est vraiment bon aussi.
 
tiens en cherchant je viens de trouver ca à l'instant:
http://salinan.memoryhole.net/autobench/

question regexp
 
Pour interpréter les puces, j'ai:
 

(pour le bloc)
 

(pour chaque élément de la liste)
 
Mais quand la liste ne finit pas par un retour chariot, le dernier élément de la liste n'est pas interprété. J'ai tenté différents moyens mais il me semble me rappeler qu'il existe une expression pour exprimer la fin d'une chaîne mais je ne me rappelle plus
 
Une idée?

oui, c'est $
en perl ca serait comme ca:
 

 
le (?: ) sert à faire un bloque non capturant, je sais pas si c'est pareil en php

les regexps que j'emploie sont celles compatibles Perl mais je ne vois pas l'utilité du ?: ici  Parce que quand je l'enlève, je ne vois aucune différence
 
En tout cas c'était bien le $ qui manquait, merci
 
J'ai donc ceci qui fonctionne nickel maintenant

c'est pas beau

Les regexps? Entièrement d'accord

l'interet du (?: ) c'est que le bloque ne va pas etre capturé (et stocké) donc tu gagne en vitesse.
Pour ce qui est de la beauté, je trouve ca plus beau que les 15 lignes d'instructions que ca remplace...

Vitesse?
Je suis capable d'en foutre partout!

si tu veux gagner en vitesse, je te conseil aussi d'eviter les truc genre ".*?", c'est tres couteux pour le moteur regexp. Mieux vaut definir exactement ce que l'on veut matcher.
 
dans on cas par exemple, mieux vaut faire ca (d'ailleurs les parenthese ne servaient à rien si tu ne voulais rien capturer) :
/\[\*\][^\r\n]*/
 
et du coup meme plus besoin du $

ben je me sers des regexps pour faire du search & replace intelligent donc j'ai besoin de faire des captures (si j'ai bien compris )

Mais tu capturais aussi le "[ *]" alors??
 
ha ben alors si c'est le bloque entre le [ *] et le retour ligen (ou la fin) qui t'interesse ca donne /\[\*\](^\r\n])/ et pi voila (moi je trouve ca joli les regexp...)

tiens oui c'est vrai c'est con en fait
Je vais modifier ça illico

[^\r\n] ca match "non \r" OU "non \n" et pas "non \r\n" donc
 
/\[\*\](.+?)\r?(\n|$)/
c'est pas équivalent à  
/\[\*\][^\r\n]+)/  
 
a priori
 
Edit : ok on s'en fout en fait, ca fait ce qu'on veut

X2board 2.2    

 
Félicitation pour ton forum, c'est du bon boulot  
 

merchi

Question con, tu utilises quoi de Smarty sur ton forum ?

ben le moteur de template
il est utilisé pour l'affichage de toutes les pages du forum et pour la construction des mails envoyés

ha ok bon d'un coté, pourquoi réinventer la roue

Ben Smarty possède tous les avantages :  
 
- approche full objet
- bonnes performances (plus de 700 online en heure de pointe sur les forums 01net, ca tourne)
- complet et extensible
- seule méthode propre de rendu, selon moi, que le moteur de template.

Si des gens s'amusent avec les regex JS
http://www.cuneytyilmaz.com/prog/jrx/

Rigole pas, j'en connais
 
e-deby: bon boulot

ca déchire  

Ben je le fais, le pingouino c'était pour l'idée de créer un interpréteur/débugger "As You Type" de regex JS
 
D'habitude je debug avec Kodos et j'adapte au JS

moi  
les URL et les emails sont cliquables grâce au JS

 
Tiens pourtant c'est ce qu'utilise ce forum-ci pour les images (forum-images.hardware.fr)

une machine rien que pour ca? Elle doit se trouner les pouces!
 
En fait d'apres ce que je vois il y a des patchs qui circulent pour ajouter le keep alive à thttpd.
 
Mais on dirait que cette verison la n'est pas patchée: je vient de faire le test avec telnet en HTTP/1.1 et il envoi un "Connection: close"...

I made a choice.
V5 de mon forum :  
pour les utilisateurs, JS non obligatoire
pour administrer le forum, JS obligatoire
 
 
pas de chichis, là où les gens qui ont le JS désactivé ne représentent que 2%.