Reprise du message précédent :

   
Tu crois que je vais les diffuser, vilain petit canard ?

Pour ça y faudrait déjà les avoir

Si tu me crois pas, tant pis , je m'en fous moi
J'ai juste profité d'un instant de bug il y a quelques temps

Ah c'est le moment où le code php s'est affiché en clair lors d'un bug, nan ? Ca a dû arriver 2-3 fois.

Oui.
Ca ne m'a meme pas servi en plus
Vu le bordel à comprendre le PHP de joce

oui enfin c'était uniquement le source d'un seul fichier en plus

nop

 
Lapin compris... tu m'expliques le lien entre mon post et le tien là?

D'abord tu m'expliques le rapport entre la phrase que j'ai quoté, et... quoi que ce soit

ben j'ai dit que ça me tentait pas, y'a pas à chercher plus que ça... le principe de la procédure stockée, c'est de faire faire à ton SGBD une partie des traitements (les avantages et inconvénients, c'est pas la question), donc je vois pas trop en quoi mon post était incompréhensible?

moi en tout cas je vois parfaitement le rapport

Oui mais dès fois y faut faire des concessions. C'est un peu lourd de tout compter à chaque fois chaque élément si tu veux rester avec une base purement normalisée (c'est l'idéal d'un côté, mais loin d'être idéal du côté performance sur certaines choses)... Un seul UPDATE à chaque nouveau post ou delete de post (rare) pour mettre à jour les dernières infos du forum concerné c'est franchement pas la mort, ça évite un tas de requêtes inutiles pour faire le listing de tes forums à chaque F5 (qui se fait en 1 requête si tu dénormalises un peu comme tu fais actuellement je présume).

Je ne connais aucun forum qui fait ce que tu dis. Même ici ça doit être dénormalisé à ce niveau je suppose et peut-être sur une table à part qui sait...

Ah oui là c'est plus embêtant si tout est mélangé au sein d'un seul forum. Pourquoi ne voudrais tu pas faire 99 forums distincts et que chaque groupe avec ses droits propres ne puisse voir que son forum lors du listing (GROUPE 5 ne voit que forum 5, etc.), qu'est ce que tu trouves chiant ? Juste le nombre imposant ? Ou alors dans le cas d'un forum unique, y faudrait une table à part qui retienne les dernières infos pour chaque groupe et tu ne rapatries que les infos du groupe concerné pour ton listing au lieu de les calculer à la volée.

Je verrais la table dans ce genre là :

group_id | last_poster | last_date | ......

puis tu fais une jointure sur le group_id du membre qui demande la page lors du listing et il aura uniquement les dernières infos de son groupe.

EDIT : Ah bin oui dans cette table tu auras 99 ID de group_id, pas le choix, y faut stocker ça quelque part sinon faut tout recompter à chaque fois.

Si ta politique de gestion des droits n'est pas aussi simple que dans ton 1er post, que tu peux faire des combinaisons de différents masques, alors cette solution ne sera pas très adaptée effectivement... Mais là c'est à toi de voir ce que tu veux vraiment faire ou non, y a pas de solution universelle.

Perso j'ai opté pour la solution requette simple, donc je met dans les tables les compteurs, oui je sais c'est crade d'avoir le nombre de post dans la table des topics, mais bon au moins ça économise du temps au select... mais ça en perd a l'insertion, ce qui est logique.
Tient faudrait que je lui fasse un trigger pour que mysql le fasse seul

c'est crade si tu veux te pignoler sur le respect absolu des normes SQL, ça l'est beaucoup moins si tu veux un minimum de perfs sur des gros forums. moi j'ai fait mon choix en tout cas! et pour ce qui est de la perte à l'insertion, bah pour les quelques millisecondes que tu perds, ça en vaut la peine pour les perfs gagnées à l'affichage!

 
C'est ce que je me suis dit, donc meme si ça fait quelques doublon vu la différence de perf c'est super interessant

tu devrais lire les 465 page de ce topic, on en a parler 10 000 fois de ce genre d'optimisation  
 

C'est mon forum, je preffere suivre mes propres idée, meme si elles ne sont pas tres lumineuse

Petit question, mesdiscussions n'utiliserait pas des DELAYED dans ces requettes d'insertion ? Car sur FA qui utilise donc un forum MD, les messages apparaissent souvant avec du retard...

nop
le retard c'est lié à un retard de replication master / slave

le master/slave n'est pas utilisé sur HFr? Au vu du souci des messages qui n'apparaissent pas tout de suite, est-ce vraiment si intéressant?

a mon avis, ce n'est pas dans son script ce systeme, c'est surement une configuration des serveurs auquel il ne peut rien toucher.

 
Ha ok  

sur HFR, non.
Le problème n'est visible que s'il y a du lag sur la replication, ce qui est rare/ne doit pas arriver si il y a suffisament de SQL ou que les serveurs sont suffisament puissant

mais ce systeme ca vient de ton code ou de la configurations des serveurs?  
 

Fabien > Même si joce a codé le forum pour que les modifications de données se fassent à travers une connexion à une base de donnée et que les lectures se fassent à travers une autre connexion, il n'est pas responsable si le réseau entre les deux est saturé ou que le serveur esclave manque de puissance (ou de rapidité au niveau disque).

le forum gère ca intelligement quand même et switch les lectures sur le master s'il voit que les slaves sont trop à la bourre

C'est gavant sur FA les "md_slave_failure"... il n'y a pas un moyen plus transparent pour gerer la répartition ?

T'as eu des md_slave_failure ? Faut que je regarde ca de plus près, c'est pas normal du tout.

Mmmm oui ok je vois le problème, c'est que la slave est vraiment à la bourre, faut que j'essaie de voir comment réduire le retard des slaves, j'ai ma petite idée.

Oui hier... aujourd'hui ça a l'air ok.

La j'ai fait un petit changement qui devrait un peu soulager les slaves.

Petite question à vous, développeurs de forum: utilisez-vous un ORM? J'ai discuté un peu du développement de mon forum avec un pote très très (très!) porté sur java, et il était super surpris que je n'utilise rien d'autre qu'un pov' wrapper MySQL pour mes accès base. Lui, il ne jure que par hibernate. Quelques saines lecture m'ont amené à me documenter sur PHP Doctrine et PMO entre autres. Cependant, la conception même de ce genre de chose me fait craindre le pire côté performances, c'est pouquoi si parmi vous certains utilisent un ORM, j'aurais bien voulu avoir leur avis et ressenti sur la question!

J'utilise un truc fait maison que j'entretiens depuis quelques années, mais je ne l'avais jamais porté sous PHP (j'ai appris le terme "orm" il y a quelques jours ). Du coup, je l'ai étoffé et je l'emploie dans mon projet actuel.
 
Et dans l'immédiat, je ne me soucie pas des performance (enfin, pas trop, sinon je ferais du Rails). Je veux d'abord que ça fonctionne, et je verrai plus tard pour les perfs.

Grave erreur, mon cher

Si l'ORM est pas trop pourri, ça peut accéler pas mal le développement. Par contre, tu perds en souplesse, et tu peux y perdre du coup en perf (ça sera plus délicat de faire des requêtes supers futées).
Coté perf, faudra pas en attendre plus qu'un truc fait main (à part si tu peux tirer profit d'un système de cache).
Après, c'est plutôt un compromis performance/maintenabilité j'aurais tendance à dire.

On verra

Yo j'imagine que ça a déja été traité 15 fois mais j'arrive pas à utiliser la recherche intra
Que conseilleriez-vous comme modèle de forum gratos (genre pas phpBB) ?
 
Pour un forum à fort traffic (2500 membres, 180000 msgs), avec une esthétique correcte.
 

punbb?