Reprise du message précédent :

Ok tu m'apprends rien
 
Néanmoins je te crois toujours pas. Rien qu'en débit théorique IDE c'est impossible.  

 
Hu, allez je te donne les miens . J'ai divisé mes temps par 15 ^^

Qu'est ce que t'en sais ?
et puis les disques dur sont en SCSI.
treve de plaisanterie, limit a raison, aceboard rulez

Des disques SCSI de 250 Go ? Hum ...

Bizzare que seulement la page d'accueil ait des temps un peu longs
 
Page générée en 0.507 secondes

la mienne se génère en +/- 30ms à comparer aux 15/20ms des autres pages, faudra que je regarde ça

hum, 0,0000 sec
 
Edit c'est fait, j'ai achevé la table des topics (ou sujets   ). Idem, j'ai divisé cette fois ci mes temps par oula !!!!. Je suis passé de 42000 ms   à 80 ms pour + de 95000 topics. J'en ai bavé pour la gestion des sondages, annonces, et post-it, mais ça fonctionne  
 
La chtite requête modifiée.

 
Je me tâte pour remplacer le Suj_1.suj_pagination <= en TOP.

 
Il y a certainement une erreur car le reste est plus que rapide..

tiens j'ai oublié le coup des post-it dans mon implémentation

oui je sais pas pourquoi ...
j'ai exactemement les mèmes requète que sur mon ancienne version ( sur l'index) et sa ce génère 10 fois moins vite...
va falloir que je revois sa...
Pourtant en réactualisant souvent je tompe sur 0.080, mais c'est encore loin de l'ancien 0.007

Bonne chance avec ça. J'ai jamais trouvé de solution pleinement satisfaisante pour les gérer, et au final j'ai opté pour une requête séparée. Ca bouffe pas grand chose (4ms de plus en moyenne pour générer la page une de chaque section - la seule où j'affiche les post-it - par rapport aux autres) mais c'est quand même con. Pourtant à priori on est obligé de faire ainsi pour conserver des temps de génération indépendant du nombre de sujets, les WHERE et autres ORDER BY sont plus couteux d'après les tests que j'avais fait.

oui, en fait c'est pas que je l'ai pas prévu au départ pour mon forum, c'est juste que ça m'est passé au dessus de la tête pendant le chapitre split/optimisation. Et pour l'instant, je vois pas non plus ce qui serait mieux que 2 requêtes séparées (surtout qu'à moins d'avoir un compteur, tu ne sais pas à l'avance combien tu as de sticky )

 
Ne t'inquietes pas c'est rien du tout à rajouter  

Avec un ORDER BY sticky, derniere_reponse effectivement Mais je te parle pas des perfs. C'est beaucoup plus chiant que ca n'en a l'air.

 
C'est faisable sans where ou presque . Regardes la requête du dessus . Tu as une partie de ma réponse. Dans ton cas, je pense que tu peux supprimer cette partie Suj_1.suj_srub_identifiant = @suj_srub_identifiant.

 
Effectivement je fais order by post it mais pkoi ça flingue les perf ?

perso j'ai changé mon order by, je le fais sur le numéro d'ordre du topic (dans la cat) ou du message (dans le topic), c'est un poil plus rapide

Oups tu fais bien d'en parler ... (oublié moi aussi ).

Bon, chuis repassé dans ma page d'index général, j'ai gagné 5ms en réécrivant un peu le brol (2 sections, 20 catégories). Le nombre de requêtes a légèrement augmenté (il s'agissait d'éliminer quelques jointures). J'ai donc gagné un chouilla en exécution des requêtes et en exécution du script. En debug, je suis passé de 27 à 21ms. Je suis donc sûr de passer en dessous de 20ms hors-debug \o/ (tous les temps que je donne sont in-debug, sauf mention contraire)
 
(c'était le moment auto-satisfaction du jour)

 
Je ne sais pas pour toi mais tu parles d'une histoire pour mettre à jour la colonne 'pagination' en cas de suppression d'un sujet ou d'un message.  Obligé de passer par 36 requêtes   . Quelle misère.

à vrai dire, pour l'instant, il n'y a que la partie affichage qui soit 100% implémentée. Faut encore que je bossse sur la partie mise à jour. Mais euh ça ne me semblait pas tant de requêtes dans mes calculs

au fait, j'aimerais bien m'assurer d'un truc en MySQL: si un thread X veut faire un lock table sur une table Y, et qu'avant le unlock, un thread Y veut aussi faire un lock sur cette même table Y: je vois dans la doc que MySQL indique que dans ce cas, la requête du thread Y serait mise dans une queue list, en attendant que le lock initial se libère. Est-ce que ça veut dire que pendant ce temps, MySQL ne rend pas la main au thread Y tant qu'il n'a pas obtenu le lock?

D'après ce que j'en ai vu dans les benchs, MySQL ne rends pas la main.

OK c'est donc bien le comportement que j'attends

D'un côté c'est encore heureux qu'il ne lui rende pas la main pour éviter des problèmes de synchro entre threads, mais d'un autre côté, c'est vachement pénalisant vu son système de lock.

Voila je pense être arrivé presque au bout de la création de mon forum, si vous pouviez me dire ce que vous en pensez, surtout de la personnalisation des couleurs via Option>Personnalisation et Modele, des tps de chargement, et du reste ...Vos premiers commentaires m'avaient bcp aider alors si vous pouviez recommencer ce serait avec plaisir
 
url : www.ybellu.com
 
compte : test / test
 

J'ai un problème pour la gestion des flags . En fait, j'utilise un découpage des posts et topics en plusieurs tables (de même pour les sondages), c'est à dire une table post/topic/sondage (soit trois tables par catégorie) par cétégorie différente. Mon problème est en fait dans la gestion des drapeuaux. En gros, j'hésite sur deux méthodes de gestion (sachant que je veux éventuellement pouvoir limiter le nombre de flags par catégorie et par type) :
 

• Solution 1 : faire deux tables drapeaux (une pour les drapeaux rouges et une pour les drapeaux verts) pour lesquelles la structure serait id_flag (auto increment), id_user, id_cat, id_topic, id_last_post. Cette solution a un gros défaut à mes yeux : beaucoup d'accès sur cette table et si je veux pouvoir limiter les flags, ça risque de faire pas mal de locks. Mais d'un autre coté, au lieu d'une table flags par cat, je n'aurai besion que deux tables pour chaque config de forum.
• Solution 2 : faire une table flags par catégorie avec cette structure : id_flag (auto increment), id_user, id_topic, id_last_post, type_flag. Cette solution semble en apparence plus simple à gérer mais cela multiplie le nombre de tables (autant que de cats) et en cas de déplacement de posts iunter-catégories, cela risque de poser quelques soucis (prévoir de déplacer les flags d'une catégorie à l'autre - ou de les supprimer).

Je ne sais pas quoi choisir en fait ...

 
Après l'identification, je suis dirigé sur ça : http://www.ybellu.com/traitement/'../index.php' , donc ça passe pas...
 
Edit: à l'application d'un modèle sur http://www.ybellu.com/'modele.php'

Ah bon ça c'est une premiere je n'ai jamais eu d'echo d'un tel probleme !
Le serveur est chez moi, je verifirais ma source ce soir mais moi j'arrive à me logger à partir de la ou je suis, d'ailleur je me souviens bien de ma partie d'identification et je trouve tres etrange que tu obtienne ça :  
 http://www.ybellu.com/traitement/'../index.php'

je sais pkoi ça fait ça :
header("refresh:".$temps.";url='".$url."'" );
les simples cotes devraient être enlevées dans ma fonction de redirection au niveau du parametre url c'est ça ?
j'ai raisonné en terme de chaine de caractères donc j'en ai mis mais j'aurais peut etre pas du...
Mais pkoi ça fonctionne sous certains navigateurs et pas d'autres ?

Pareil : j'ai testé et pas de soucis.

perso j'ai penché pour le split des tables drapeaux, histoire de gagner un petit peu de place en ne stockant pas la catégorie. Au fond, si tu dois déplacer un topic vers une autre table, la procédure est la même pour les drapeaux, ce n'est jamais qu'une table en plus (note qu'ici-même, tu le perds carrément).

Et sinon vous en pensez quoi ?

Hmmm mwais je pensais en fin de compte prendre la solution 2. Et au pire, plutot que de t(ansférer les flags, peut être que je les effacerait. Enfin je verrai.

 
Oui, en fait c'est avec Opera que sa passe pas. Pas de problème avec IE, bizarre quand même !?!

fiou j'ai enfin trouver la solution pour afficher les icones de "nouveaux" messages !
reste plus que a tester maintenant !

faudrait aussi que je me trouve des graphiques libres que je puisse intégrer à mon forum en lieu et place de ceux que j'ai chourrés dans Windows

http://gtkmm.org/docs/gtkmm-2.4/do [...] Stock.html
si sa peu te servir

Pour savoir si quelqu'un a déjà posté dans un sujet et donc pour lui afficher une icone particulière devant le sujet en question, avez vous une table "participation" dans laquelle vous stocker id_user et id_sujet ou effectué vous une requete dans la table message pour voir s'il existe des messages appartenant à la personne ?

J'ai vu que phpBB se contente de comparer la date du dernier message avec celle de la derniere connexion en cours pour dire quels sont les messages non-lu ...
Mon avis : Je trouve ça léger car si je me connecte, j'ai 50 message non lu dans diferent topic, je me déco et je me reco donc ma nouvelle "derniere connexion" s'actualise et HOP je n'ai plus aucun message non-lu...
 
Je sais bien que stocker un état par topic et par user reviens a generer une énorme table mais n'est ce pas mieux au final du point de vue des possibilités qui en résultent ?

Si bien sûr. D'ailleurs c'est une très bonne raison de détester phpBB.