Reprise du message précédent :

 
Rien à voir avec le split
 
C'est pas en temps réel ton truc, c'est lourd quand même. Par contre y'a de l'idée quand même, possible de mettre un champ supplémentaire dans la table de topics pour savoir dans quelle base taper pour le contenu du message, mais dans ce cas les nouveaux messages vont quand même dans l'ancienne table sinon c'est injouable dans l'affichage. Ca reste difficile à équilibrer quand même, à la limite autant faire un au moment de la création un système qui met les réponses du topic dans la table la plus légère parmi l'ensemble de n tables prédéfinies.
 
Ca reste beaucoup de bordel pour en définitive pas grand chose, ça ajoute juste un aiguillage à l'arbre qui lui est dans le code PHP.
 
A voir mais beaucoup de bordel pour un résultat dont je ne suis pas certain

 
J'ai une question, comment tu vas bencher ? Parce que simuler un trafic important sur une table de grosse taille est pas forcément simple Si tu fais juste le déplacement sans simuler les requests  / sec sur la table cible, on peut pas juger
 

Sinon pour PHP on est d'accord que c'est lourd, le problème restant d'assurer qu'un changement de style HTML ou autre ne fasse pas merder la mise en page de tous les anciens messages. Pour celà il y a nécessité d'utiliser ses propres codes dans le contenu stocké dans MySQL pour l'évolutivité. Et je crois que quasi tous les forums PHP le font.
 
On touche le font du problème, différence entre facilité de programmation et optimisation à outrance
 
Faut-il réellement optimiser au prix de tout le reste ?

 
Le tutoiement est de rigueur sur ce forum. Garnement!
 
Sans rire, je préfère le vouvoiement. J'ai fait des efforts au début pour m'adapter mais vouvoyer pose une certaine distance entre les hommes que j'apprécie.

Personnellement ça ne me gêne pas le vouvoiement, chacun son style, tant qu'on ne l'impose pas aux autres

 
Je vais déjà le faire "à vide" pour voir ce que cela donne avec une table de 300 000 messages. Je referai les benchs plus tard avec des clients en C émulant un utilisateur et passant donc par le serveur web histoire d'avoir un environnement un peu plus réaliste.

oki, thx
 
Aussi, amusant de voir comment le fait de passer les images sur un autre serveur allège la charge.
 
Apache reste un programme relativement lourd tout de même

 
Je ne remets pas en cause la stratégie de stockage des smileys. Par contre, j'aimerai bien voir le code de la fonction php qui se charge de remplacer les "codes smileys" par les urls. S'il n'est pas possible de préalloue et qu'à un moment ou à un autre, elle fait des realloc, c'est la misère assurée pour la cpu.
 

 
Ca dépend de pas mal de paramètres ça . Si on a le temps et les compétences, autant produire une architecture et un code optimisés. Il est rare qu'on ait à le regretter et la réciproque est loin d'être toujours vraie. La programmation, c'est un peu l'inverse des mathématiques. En maths, avec trois lignes de théorèmes, on peut résoudre des milliers de problèmes différents. En info, pour trois problèmes différents, il faut parfois écrire des milliers de lignes de code. Bref, je veux dire que pour produire du bon travail, un matheux doit être fainéant (principe d'Ockham) alors qu'un programmeur doit être bosseur (principe de DocMaboul).

le stockage des codes smileys dans la DB ça suxe (enfin je veux dire: l'inventaire des codes smileys). Une option que j'ai l'intention de décliner pour ma propre implémentation, ça me semble lourd

Le code de ce forum appartient à joce ( et plus globalement à Presence PC ), moi j'y ai accès mais je n'ai en aucun cas de droit dessus, donc c'est à lui qu'il faut demander ça

QSLP

 
Je ne vous le fait pas dire.
 

 
Qu'est-ce qui vous fait dire ça?

Et bien déjà l'occupation mémoire et la charge qui est affectée de manière assez nette en fontion du nombre de process apache, je ne mets pourtant que le strict nécessaire comme modules avec ( PHP + mod_rewrite et les standards ). Mais bon c'est pas non plus évident d'avoir mieux pour les mêmes fonctionnalités.
 
et puis y'a pas de secret, bcp de process -> bcp de ressources...

 
En fait, je parlais du code source de php et non pas du forum. Mais il est vrai que pour ça, il faudrait que je sache quelle fonction est appelée pour faire le replace (dans l'hypothèse où le job est bien fait par un replace ou quelque chose du même style). Déjà, on peut préallouer une string en php?

tu fais ce que tu veux, mais ca me fait bizarre d'etre tutoyé sur un forum
 
sinon, c'est pas seulement sur ce forum qu'on tutoie mais sur tous les forums.
 

en fait le + simple, serait de faire une table par sous-cat pour les reponses. ca diviserais la table en dix partie environ pour chaque cat.

 
vouvoyé, tu veux dire ?
 

 
Pas tous, mais la majorité en effet.
Idem pour les mails, j'ai tendance à tutoyer
Et ICQ/MSN aussi.

Ca je confirme. Encore plus en environnement Win32 je dirais même ...
 
Paar contre, je rejoints l'opinion des "contre le stockage des codes html des smilies en BDD" : un certain nombre de forums le font (PBPbb ou INF par exmeple) et ce sont de très loin les plus lents. Le parsing à l'affichage bien  que lourd est de loin plus léger que le parsing en BDD.
 
Et MySQL (ou autre SGBD) qui va lire et ramener les posts de la BDD (du HDD en fait), va mettre fatalement plus de temps en lisant un post avec plein de codes HTML plutot qu'un post identique quant à son contenu mais uniquement avec des codes UBB ...

Oui enfin, il faut relativiser la quantités de données html dans un post je pense. Pour ce que j'ai du réaliser jusqu'à présent, j'ai effectué le parsing dans la base de données. C'est vrai que c'est pas spécialement pratique

c'est surtout non evolutif.

 
Bon, he bien en tout cas, je viens de jeter un coup d'oeil à l'implémentation de la fonction str_replace du php et, c'était prévisible, elle effectue bien des réallocations.
 
Pour ceux que ça intéresse, il faut aller voir les fonctions et macros suivantes (pour php 4.1.2) :
 
str_replace (ext/standard/string.c)
php_str_replace_in_subject (ext/standard/string.c)
php_str_to_str ou boyer_str_to_str (ext/standard/string.c)
smart_str_appendl_ex (ext/standard/php_smart_str.h)
smart_str_alloc (ext/standard/php_smart_str.h)
 
Dans la doc, je n'ai pas trouvé non plus de fonction pour préallouer une chaîne à une certaine longueur.
 
Au pif-o-mètre, je pense qu'il faudrait donc ajouter deux fonctions dans le runtime du php (my_speedy_gonzales_str_prealloc & my_speedy_gonzales_str_replace).
La première pour préallouer la chaîne contenant le résultat du replace et l'autre pour faire un replace sans réallocations ou prenant un paramètre lui indiquant une stratégie de réallocation (par exemple un coeff multiplicateur ou un nombre d'octets à ajouter).

 
C'est normal parce que chaque process va devoir mapper dans son espace d'adressage les librairies (les modules et autres .so nécessaires à l'exécution). C'est aussi pour cela qu'il vaut mieux utiliser un petit nombre de process avec pas mal de threads. Encore que ça dépend de l'implémentation des threads après. J'avais entendu dire que linux ne gérait pas les threads mais qu'il les émulait via des fork. C'est vrai ça?

Aussi : j'avais oublié de le préciser.

sa consomme beaucoups plus d'avoir plusieurs index dans une bdd ?

Au contraire ca économise.

 
ça consome en place sur le disque!
 
puis pour le temps proço ça depend...
pour les select ça alege, pour les insert ça alourdi
 
ça depend de ce que tu veux faire avec ta bdd quoi

ça consomme en place (edit: yvele kestufoulà à me griller )
 
faut voir si t'en as vraiment besoin (est-ce que ton index sera utile à des requêtes?) par rapport à la place que ça prend.

j'ai grillé drasche!

Genre je peu m'amuser à mettre 4 index pour la mème table, sa sera équilavent êndant les SELECT?...
Et sinon, plus l'index contient de champs, plus c rapide lors des select ? ou c plus lent ? Parce que je fais un select avec 3 WHERE (WHERE 1="1" and 2="2" and 3="3" )
je fais un index pour ces 3 champs. sa sera plus rapide que 2 champs ?
mici

si tu fais toujours tes select sur une combinaison de 3 champs par exemple, et ben il sera plus interressant de faire un seul index sur les trois champs en question.. au lieu de les indexer à part

c ce ke g fait
Et si aprés je dois faire une recherhce sur un seul des 3 champs, sa sera plus long ? si je créer un autre index avec qu'un seul champs sa ira mieux non ?

t'as essayé ça?

 
ben ouèp..
 
enfin plus long que si tu l'avais mis dans un index à part quoi..
 

 
ben oui..je pense que la,pour le select ça va être plus rapide..
 
mais apres si tu veux faire un insert, imagine tout les index qu'il aura à générer et à gérer.. truc de ouf quoi  
 
bref ça depend si tu compte avoir des insert performants ou pas..
 
 
les index, à consomer prudemment, avec modération  

pas encore mais g lu sur mysql.com que SQL prenait l'index qui ramène le moins de ligne...

ok, c vrai que les insert sont un peu long je trouve, mais g bien plus de select que de insert pour mes forums donc je vais garder mon index à 3 champs merci

juste pour dire :
 
ça va mysql est quand meme bien rapide..  
la on fait des inserts sur 4 tables... et la derniere table se tape une clef primaire sur 4 champs... et on fait la race d'insert.. on a 800000 enregistrements à faire en un seul hit  
 
et ben meme avec 4pk, il met à peine 11 secondes à tout remplir (en local) et 2 secondes connecté en lan..
en .NET avec le driver bytefx (le tout dernier! il est sorti aujourd'hui )
 
 
 
 
mais bon on peu pas comparer php à .NET avec un driver natif..

hum g fait un test en local avec 1 000 000. 20 seconde sous winblows et media player (love robzombie).

ouèp j'ai oublié de préciser : serveur mysql sous windows 2000  
 
 
edit: inserts plus rapides à faire que sous oracle

tant pit si je passe pour un boulet, mais j'aime bien posser des questions
C koi la différence entre mysql, postresql, oracle ?

ben c'est des SGBD qui n'implementent pas les meme features quoi..    
 
par exemple postgresql et orale gèrent les triggers.. procédures stockés.. pleins de trucs.. toussa quoi.. alors que mysql non...
 
 
 
renseigne toi sur les triggers, procedures stockés..
 
(sinon y a aussi microsoft sql server.. j'essaye un peu comme ça, et c'est vraiment pas mal.. non spa un troll )

regarde ici :
 
http://fadace.developpez.com/sgbdcmp/