Reprise du message précédent :

 
Si vous voulez, j'ai assez confiance en mon code de ce côté-là. Le problème sera plutôt la bande passante, 256 Kbits (sic!).
 
Ah, aussi la bécane de mon pote est un athlon 2000+ (enfin, quelque chose comme ça je crois) avec 256 Mo de ram (ça j'en suis sûr).

Faudrais que t'ajoute le Alt-S pour valider la réponse, c'est primordial

http://agnes.vestris.com/en/
 
c'est un de meilleurs formus du marché, c'est le seul qui a résisté à la connerie de Jean-Paul Ney, et je peux te dire que c'est du critère sérieux.

tient je connaissais pas ca
 
moi je fait tab enter

 
C'est quoi sa connerie?

le machin qu'il a entre les 2 oreilles, c'est un gros con. En fait il est un peu malade psychologiquement aussi. Il a une obligation de soins.

 
D'accord. Sur ce, je vais rejoindre ma femme qui m'engueule depuis une heure au téléphone. Bon flood à tous

Merde Doc', c'est rapide ton forum là
 
*bluffé*

ouais enfin y'a pas beaucoup de messages pour l'instant donc pour le test c'est pas vraiment valable.
Cependant c'est sympa

Beh quand tu mattes les temps de génération, même à vide, PHP/MySQL, tu fais pas ca

tu peux trés bien trafiquer le temps de generation pour bluffer les autres

Moui bon, en même temps, faut pas voir le Mal partout

je crois que certains ne digèrent pas trop la réalité

Toi aussi tu penses que c'est un phpbb skinné avec un temps de génération aléatoire <1sec?  
 
Ca n'intéresse personne ma question? Enfin je vais m'occuper de ça plus tard si j'y arrive

DB Time 0 ms (0.00%)
 
Donc en fait tu as du cache c'est sa ?
En gros c presque un forum en html là...
Puisque l'interaction avec la BDD est nul ?

y en a un qui est chez free, et l'autre qui est à Marseille avec Wanadoo

bah c'est ses caches qui font que le temps qui fait qu'il y a plus d'accès BDD (en l'occurence vu qu'il y pas grand chose, tout reste en cache au niveau du serveur en C).
 
mais bon même avec plein d'utilisateurs et de topics, ça doit aider.

 
si MisterMaboul est chez mamadoo, sa crédibilitée va baisser (je déconne)

avec pleins d'utilisateur qui postent tout le temps le cache est quand même bcp moins utilisé

sur le forum : "Not Found
 
The requested URL /tests/mabouls_world/{U_FORUM_EXPAND_ALL} was not found on this server."

y a combien de posts par pages ?

 
non, le cache est actualisé par les posts.
 
l'ideal, serait de faire un Write-Back en C.
 
mettons que tu as un cache à topic.
 
quand tu as un utilisateur qui crée un nouveau topic, il va se retrouver en haut dans la liste des topics.
 
le topic, tu le crées uniquement dans le cache spécialisé aux topics du serveur et pas dans la BDD.
 
et après pendant un temps mort, tu actualises la BDD.
 
ce qui fait que si tu construit bien le truc, tu peux te démerder, pour une majeure partie des accès BDD qui soient éliminés par le cache, sachant que la création d'un nouveau topic l'actualisera.
 
en fait faut faire un mimétisme des caches CPU & GPU qui permettent de rendre transparents des opérations complexes.
 
si tu réfléchis bien, tu peux avoir une configuration du style:
1500 utilisateurs enregistrés
2000 topics
 
10 topics visibles (en haut de l'affiche) => en cache
 
20 topics crées à l'heure =>  
crées en cache, actualisation BDD différée lors d'un moment de faible charge BDD.
on limite le cache à topic, de toutes manières si on que 10 topics visibles, un nouveau topic évicte le dernier topic visible du cache à topic.
 
10 posts crées par secs =>
pareil actualisation en cache, actualisation BDD différée
sauf que là y'a association post/topic....
 
enfin bref.
 
les caches spécialisés y'a rien de mieux pour booster les perfs.
 
enfin je dit ça, faites comme si j'avais rien dit, j'essayes d'appliquer des règles d'optimisation hardware à un forum

y a un cache de ce style pour le forum PPC
Ce qui est plus problématique c'est de faire un cache pour le contenu des topics

vi j'avoues que c'est ce qu'il y a de plus tendu d'un point de vue logique.

pas uniquement logique, mais aussi au niveau place mémoire
Le forum de docmaboul pourra pas toujours tout foutre en cache si y a énormement de topic sur le forum et en particulier des gros topics, avec pleins de pages, donc il sera fucké à un moment ou un autre

 
J'ai fait mes tests avec une base de données de 500 000 messages, ce n'est guère plus lourd sauf pour la page d'accueil en mode connecté.
 

 
Ma femme est directrice chez ft
 
joce> D'ailleurs, je ne comprends pas pourquoi sur ce forum, je suis obligé de cliquer une demi-douzaine de fois pour avoir l'affichage d'une page alors que sur ppc, ça passe nickel. Je pense que ça vient d'une interaction avec le proxy de ft parce que ça ne le fait pas non plus sur les autres sites (ma femme m'a dit que ça lui arrivait avant sur un forum phpbb). Le plus chiant, c'est pour l'envoi des messages où je suis obligé de me taper des back-next-envoyer pour me rendre parfois compte que j'ai posté plusieurs fois le même message (ah oui, du coup, je suis privé de recherche aussi).
 
 

 
Ce n'est encore qu'une version alpha
 
bjone> Pour votre idée de "délayer" les insertions bdd, j'y ai pensé mais ce ne sera pas avant une version *très* stable (c'est un poil dangereux ces petites conneries).
 
bjone&joce>Pour les caches topics/messages, le fonctionnement est le suivant.
 
Les topics sont accessibles via une table de hash sur leur id. La table est "adaptive", c'est-à-dire qu'elle compte les collisions et se réalloue en recalculant les clés dès qu'il a trop de collisions ou que la table est presque pleine (80%). Au niveau logique, cette table est commune à tous les forums. Dans le cache d'une structure forum, on trouve 6 listes d'id de topics. Une triée selon la date du dernier message, une autre selon les titres, une dernière selon les auteurs et 3 autres avec respectivement les tris inverses. Ces listes sont limitées en taille "arbitrairement".
 
Bref, lorsqu'un utilisateur regarde par exemple la troisième page d'un forum, j'ai un petit algo qui va déterminer la manière optimale d'utiliser les caches selon le tri qu'il utilise. Logiquement, je regarde les listes de topics de ce forum sous cette forme
- topics de la liste du tri utilisé
- no man's land (topics n'étant jamais dans une liste)
- topics de la liste du tri utilisé inverse
 
Après, il ne reste plus qu'à demander les infos à chacun en respectant quelques règles de logique. Forcément, plus la taille des listes est grande, moins j'ai à faire d'accès BD (topics dans le no man's land => accès BD). Si j'étais sûr d'avoir un serveur avec 4Go de ram, je pense que je chargerais les listes entières de topics (enfin, d'ids) en mémoire.
 
Bon, pour revenir à nos moutons, lorsque l'utilisateur demande la troisième page, (dont les id de topics sont probablement entièrement en cache et sinon qui vont y finir), pour chaque id, le code appelle une fonction se chargeant d'aller voir dans la table de hash si la structure des données du topic est présente et sinon, elle la charge depuis la bd (ce n'est pas encore tout à fait optimisé).
 
Il est nécessaire d'avoir un tel pattern parce que le garbage collector peut décider pour plusieurs raisons de virer le contenu d'un topic de la table de hash. En pratique, il ne doit virer que les topics les moins lus. Pour ce faire, j'entretiens un compteur d'utilisation au niveau de la structure des données en cache, compteur qui est incrémenté à chaque utilisation du topic et décrémenté toutes les secondes. S'il tombe à zéro, je le dégage de la mémoire mais pas son id des listes (après, le gc fonctionne aussi selon des modes un peu plus "agressifs" lorsque la quantité de mémoire libre baisse sérieusement).
 
Pour les messages, le fonctionnement est à peu près le même. Une table de hash pour les données, une liste d'id de messages par topic (en fait, il y en a une deuxième pour représenter la discussion sous forme d'arbre mais elle n'est pas nécessairement remplie). Quand un utilisateur veut voir la troisième page d'un topic, la mécanique est exactement la même en plus simple (puisqu'il n'y a qu'un seul tri). Cela fait que ne restent en mémoire que les ids des messages et les données des messages les plus lus et non pas tous les messages avec toutes les données associées.  
 
Comme tout ça fonctionne avec des tables de hash "adaptives", le volume des topics/messages n'influe que très peu voire pas du tout sur les temps de génération et ne restent en mémoire que les données effectivement utilisées, ce qui permet de limiter sérieusement la quantité de mémoire requise.
 
Donc, je ne m'amuse pas à charger un blabla dans son entier et un topic de 200 000 messages ne prendrait "que" ~800Ko de ram pour les ids et quelques dizaines de Ko pour la structure topic et les structures des messages effectivement lus sur ce topic.
 
En espérant avoir été à peu près clair

total respect à DocMaboul, j'en ai profité pour recompter les forums et y'en a 29 au lieu de 32

Tu as combien de topics / posts en cache (environ) à un instant quelconque?

vous faites comment pour faire des systèmes de cache en ram comme ça en php ?
faut passer par les sémaphores ?

Ou alors passer par des tables HEAP MySQL

mouais, parait que dans la pratique c'est à peine plus rapide que le myisam...

docMaboul, j'ai l'impression que tu recodes une BDD et le principe des indexs avec ton hash adaptatif
Plutôt que de faire ca, t'as pas essayé d'utiliser un serveur MySQL Embedded histoire de voir ce que ca donne, et t'éviter les connections à la db ?

utilise SQLLite, smieux

Berkeley DB

 
Mouais... on peut le voir "un peu" comme ça. Disons qu'un sgbd, c'est beaucoup plus souple que mon bousin super hard-codé (en comparaison) mais aussi moins performant parce que plus générique et faisant donc appel à plus de couches.
 

 
Vous pensez vraiment que ce serait plus rapide ? (au fait, pourquoi cette ancienne question sur la version de mysql?)

Le meme systeme de cache de Docmaboul est utilisé sur www.skyblog.com (j'y taffe), et avec 2000 utilisateurs en ligne, 350 000 inscrits, les disques durs crachent quand meme continuellement 30mo/s.
 
les serveurs sont des bi xeons 2,4 ghz, 2go de ram, DD 200go en raid5, sous openBSD, sur une LS 100mbits.

Pourquoi j'obtiens :
 
Apache/2.0.48 (Unix) PHP/4.3.4 ServerApache/2.0.48 (Unix) PHP/4.3.4 Server at 212.85.152.238 Port 80
 
quand je fais :
http://212.85.152.238/tests/maboul [...] AND_ALL%7D

edit2: ils ont combien de serveurs?

Ca peut juste vouloir dire que Apache est compilé avec PHP...
Je me suis amusé à faire un cgi en VBS ( ) et c'était indiqué pareil quand y'avait des erreurs...

 
Ok, merci.