Reprise du message précédent :

non
 
maintenant oui

il a deja 2 ans

Bon aniv

l'est jamais trop tard pour renommer ton forum

uen version payante pourrait s'appeller Cash Board  

bon, ça avance, je sais créer des topics
faut encore se taper le reste /o\ (édition, puis création et édition de messages)

ils parlent bizarrement ces belges
en france on dis "je peux"

s'il peut le faire c'est qu'il sait le faire

 
en Belgique pas

 
Ça marche aussi dans l'autre sens, en Belge : s'il sait le faire c'est qu'il peut le faire

je peux éditer et effacer aussi maintenant \o/

c'est bien il apprend vite (/o\)

nan mais je vais vite reprendre mes bonnes habitudes hein
 
(et hop, j'emballe le postage et l'édition de messages)

 
je peux poster un message
 
c'est une possibilité, pas une capacité
 
 

Puisque mon forum a maintenant un nom, l'url a légèrement changé: http://drasche.dyndns.org/board999/index.php
 
C'est toujours la même chose en apparence mais ça a bien avancé. Il ne me reste que la gestion des drapeaux pour avoir un truc convenable  (et comme d'hab, il ne fonctionne qu'en lecture seule pour l'instant)

Ptain en lisant la doc de MySQL, je découvre enfin un moyen de balancer 1000 rows d'un coup pour de vrai, suffit de spécifier plusieurs sets de values dans l'insert
 
Ca sera pour demain, ça demande trop de modifs à mon prog pour ce soir.
 
edit: pour les fans: http://www.nightwing.easynet.be/fi [...] chine2.zip (version qui attaque l'API MySQL directement)

fallais demander
 

ça va vachement accélérer mon processus de flood ça

Le temps de déplacer mon serveur vers un autre datacenter j'ai du migrer mes bases sur un serveur temporaire pendant 72h, il y a une dizaine de jours. Bah c'est fou ce que travailler avec un hébergement sous-dimensionné permet de faire en terme d'optimisation
 
J'ai pu remarquer un gros goulet d'étranglement au niveau de la sélection des messages que je n'avais pas constaté avant. Les jointures sont beaucoup plus couteuses que ce que j'avais imaginé. En l'occurence, faire une jointure même sur une table très simple de type texte_id / texte_contenu pour récupérer le texte des messages est une très mauvaise idée quand la table est grosse est n'est pas en format fixe. Idem pour les flags sur une table en MyISAM. Quelques modifications de la structure DB plus tard et avec quelques scripts re-écris voilà ce que ca donne :
 

 

 

 
Et ce avec une pointe à 974 connectés hier. Même à 300 requêtes SQL par seconde le serveur ne bronche pas un poil. Les 330 slow queries concernent juste des opérations manuelles (alter table et compagnie) et divers recoupements IP pour la validation des inscriptions. Bref, j'arrive vraiment à quelque chose de robuste là

En parlant jointures, j'ai finalement opté pour éviter un maximum, on dirait qu'il y a des gains intéressants à obtenir (merci Sky du conseil), et en fait, c'est surtout plus facile à optimiser au niveau MySQL, suite à une petite lecture du manuel hier

UPDATED

désolé, j'y remédie de suite

 
Tu peux donner des exemples ?

ça te plait ?

Dans l'index principal, j'ai un combo de jointures sections/catégories/sous-cat/privilèges que je vais morceler en petites requêtes. Le principal problème me vient des sous-cats: toutes les catégories n'en font pas forcément usage, donc les sous-cats seront chargées indépendamment, c'est une certitude. Pour le reste, faut que je réfléchisse encore un peu.

Parfait merci

 
Entièrement d'accord

 
Interessant. Toutefois, jusqu'ou doit-on dénormaliser la bdd . Cela ne represente-t-il pas trop de contraintes par la suite pour maintenir cette BDD ?. Le but de la normalisation étant justement d'éviter la redondance d'informations et de faciliter l'entretien de la base.

Justement, je n'ai aucune redondance d'informations. A 2 astuces près rendues indispensables pour rendre les performances le plus indépendantes possible de la taille du forum, ma base est parfaitement normalisée.
 
Il y a juste les sondages, qui sont gérés de manière pas très clean, mais c'est car je les ai codé il y a 3 ans et que j'ai jamais eu le temps de les modifier depuis

 
tout à fait, et le but de la dénormalisation est d'améliorer les performances au détriment de la redondance.

ouais donc ma base est "assez" dénormalisée
(mais du coup, les perfs ne sont plus dépendantes que de la quantité d'informations affichées et non plus du nombre de messages/topics)

Bonjour à tous
 
 Voilà, je suivais le topic depuis un moment et ayant enfin un peu de temps libre en ce moment, je me lance pour faire un forum en PHP. Rien de bien original, j'ai assez peu fait de PHP dans ma vie, je fais plutôt du Java au boulot, mais j'espère bien apprendre et comprendre un peu mieux comment ça marche.  
 
Pour l'instant je dev sous Eclipse sur mon poste et je fais mes tests en local. J'aimerais publier mes versions, que me conseilleriez vous comme hébergeur qui gère le php/mysql et ait des temps d'accès corrects svp ?
 
Merci d'avance et bravo pour les autres forums, ça me bluffe

Bonjour tout le monde,
 
Comme certains d'entre vous le savent deja je suis aussi entrain d'essayer de faire mon petit forum ... Il y a quelques temps j'en avais fait un qui aurait pu s'appeller usine_a_gaz.com tellement il était lent, et donc je suis entrain de le reéecrire de A à Z en essayant de mieux l'optimiser cette fois-ci. Depuis quelques jours je coince sur une requette, celle qui permet d'afficher ce genre de page : http://forum.hardware.fr/forum.php3 . Après avoir demandé conseil a JagStang il m'a conseillé de vous présenter ici mon MPD parceque je suis pratiquement sur que je suis entrain de chercher midi à 14h à cause de ma mauvaise conception des tables. Et donc voila :
 
 
Il y a 4 tables prises en compte :
 
1ere : Contient la liste de tout les "sous-forum" (Programmation, hardware,...) selon la construction suivante : ID , GROUPE (je rassemble mes sous-forum en groupe par exemple Prog et Hardware seront mis dans le groupe "Informatique" ), description
2ème : La liste de tout les sujets, selon la construction : id,forum_id (a quel forum il appartient),titre, nb_vision (nombre de fois que le sujet a  ete lu)
3ème : la liste des reponses aux sujets, selon : id,sujet_id,auteur,creation ( la date ),texte
4ème : Une table qui me permet de decider si tel ou tel utilisateur pourra voir ou pas le forum en question , selon : ID, username,forum_id
 
Et donc voila ... j'ai essayé de developper plusieurs requettes affichant  la fois les info sur le sous-forum, sur le nombre de sujet qui y figurent et quel est la derniere réponse postée (son auteur et la date) mais je n'y arrive pas. A votre avi il s'aggit d'une mauvaise conception de mes tables ou c'est juste que j'ai pas chercher assez longtemps (snif 3 jours sur la meme requette et 50 personnes harcellées par MP)
 
En tout cas merci de m'avoir lu jusqu'ici , et merci d'avance

 
Donc tu récupères en plusieurs requêtes ce que tu pouvais faire en une seul si j'interprète bien ?

Ben fait c'est assez logique : plutot que de faire des jointures lentes et qui peuvent être évitées, faire des petites requêtes plus nombreuses mais ciblées peut rapporter en performances. Enfin je le pense ...

En général, une jointure évite une requete dans une boucle donc c'est toujours benefique dans ce cas la. Maintenant, je vois pas trop un cas precis ou il y a une jointure qu'on peut virer sans faire un nombre de requete qui depend du nombre de resultats (boucle).

la jointure evite surtout le produit cartesien qui est toujours assez lourd (dites moi si je me trompe)

 
Je pense que dans certains cas, tu peux regrouper toutes les informations en 2 requêtes tout en évitant justement ce problème de jointure entre 2 tables. Je vais tester ce soir...

En attendant vos commentaires a propos de mon database, j'ai sorti 2 requettes qui , couplées font exactement ce que j'ai besoin .. Mais vous voyez sans doute le probleme :  

 
Vous voyez bien que le nombre de requettes deviendra tres rapidement enorme (surtout si j'utilise le meme type de systeme pour lister les sujets). Question : Ceci ne transformera pas mon forum en usine a gaz? N'y a t'il pas un moyen de "fusionner" ces 2 requettes en sachant que mon hebergeur tourne sur Mysql 4.0+ ?

Et le lock de 2 tables dont l'une souvent appellée...

Pas forcément.
 
Prends un forum avec des sous-catégories. Trouve moi un moyen d'afficher les catégories et sous catégories (comme phpBB, pas comme ici) - c'est à dire tous les posteurs de toutes les dernières catégories - en utilisant une jointure.... à moins d'avoir un truc crade ou de débutant, c'est pas faisable