Reprise du message précédent :
Hop, nouveau design made in ProgWorld    
Pas encore finalisé mais franchement j'adore...
 
http://www.programmationworld.com/ [...] pu_accueil

 
Juste une question qui a rien à voir : comment tu obtiens la valeur   "Client : Cette page a été générée en 0.406 ms." ?

moi je posais la question plutot pour le cote serveur

moi en fait pour les deux

http://drasche.dyndns.org/board999/
 
version optimisée, tourne sur ma configuration "Newton" (Athlon 650)
 
Je ne suis pas du tout mécontent des perfs (mais c'est toujours "readonly" pour l'instant, pas de login, pas d'inscription)

Drashe tu va mettre en place un url rewritting ?
J'ai vu que tu as besoin de spécifié la cat pour atteindre un topic, j'en conclue que la clé primaire d'un topic est une clé composé de topic,forum et cat et non d'un simple autoincremente non ?
 
Sinon rien a voir : qui sait comment gerer le fait que a certain moment on ai des pertes dans les tables et que l'on doit faire un optimizetable() ...

Total page generation time: 1 169.99 ms

sur le fond rien a dire, sur la forme, j'aime pas les 2 icones bleu et rouge des drapos()
la taille laisse au pseudo est enorme dans les threads ou c'est juste chez moi?
 
sinon j'aime bien le fond bleu clair

bon alors:
1/ url rewriting pas prévu pour l'instant; oui, j'ai besoin de connaître la cat vu que chaque cat a sa table des topics
2/ refresh
3/ j'ai bien l'intention de changer toutes les icônes (tout est hacké hors de Windows donc spalibresapu)  merci

Une table par cat ...c'est pas très Merisien ça

Je te le fais pas dire. Pour ma part j'ai uniquement 2 tables pour les messages et je m'en porte pas plus mal. Ceci dit les avantages cités plus haut (gain de place, performance, possibilité de récupération en cas de crash) ne sont pas négligeables. Quoique, pour le coup du crash ... je reste sceptique. Un crash cache nécessairement quelque chose. En 3 ans j'ai eu une seule table corrumpue sur mon forum (error: Record at pos: 2728672 is not remove-marked / error: record delete-link-chain corrupted) et myisamchk m'a réglé ca en quelques secondes  

Et sinon faites vous comme phpBB : separer le contenu des message de ses informations en deux tables distinctes ?

 
Pas mal du tout, surtout avec autant de messages..

merci
pis en obtenant justement la formule pour avoir des temps de génération stable où qu'on soit, j'ai même plus besoin de générer les 2 méga-DB que je m'étais prévues pour la fin (surtout que j'ai un problème technique: avec une si grosse demande, DaFloodMachine bouffe toute la RAM et plante à la génération des topics  Eventuellement, je réviserai ce truc )

Sans vouloir jouer le rabat-joie. Sur les premières pages des topics, tu oscille entre 500ms et 950ms, or tu n'as pour le moment aucune écriture (gros point pénalisant en MyISAM) et très peu de connecté simultané. Même sur un 650Mhz, c'est perfs me semblent fort moyenne

euh j'oscille entre 30 et 70ms
 
url?

faut arreter avec la theorie et Merise, c'est bien joli dans l'absolu, mais en pratique c'est pas applicable si tu veux des perfs un tant soit peu correct.
Ceci dit je vois aucune introduction de redondance d'information en utilisant un table par cat.

une url c'est stupide vu que comme tu n'as pas de modification, quand tu refresh, tu tombes sur le cache MySQL. Par contre, je vais te faire un screenshot.

bin je comptais sur le cache moi, malin
sinon je veux bien aussi, mon premier accès au serveur m'a généré ma page en 1.5 seconde

Le cache, il va être super utile une fois que tu auras des insertions

chuis entraint de refaire le design et le code de mon forum, le design il est

fais péter

XHTML Transitional
 
et vous attendez que je le finisse, c'est la nouvelle version avec mes extensions personnalisés et tout

petite question : ya du monde qui utilise les sessions ? niveau sécurité c'est quoi le mieux entre les cookies simples et les sessions ?
 
c'est modifiable un cookie avec un éditeur de texte ?

 
Oui
 
Une des règles de conduite concernant la sécurité c'est de ne jamais faire confiance dans tout ce qui vient du client

 
C'est une qestion que je me suis toujours posé aussi.
Sessions, deux types de sessions : avec cookies et sans. Sans cookie, l'id de session est passé par l'url. Avec cookie l'id est stocké dans un cookie qui est détruit à la fermeture du navigateur. Sur le site de php, ils indiquent que ce n'est pas sécurisé parceque l'id navigue en clair....
Les cookies, je crois que tu peux les modifier (jamais testé) et surtout je crois tu peux très bien les recopier d'une machine à une autre.
 
Donc rien n'est sûr à 100%. Mais je crois qu'en programmant des bons cookies pour un forum ça devrait suffire et ça évite de retaper le mot de passe à chaque fois. Ici ça marche comme ça, ça fonctionne pas mal.Bien évidement, si tu mets le mot de pass dans le cookie ça pourrait aller moins bien

Ouais, j'en ai parlé avec joce sur ICQ faut aps le laisser en clair dans le cookie

ca semble logique tout de meme  

 
tres bien tres bien, une explication s'impose, je n'ai pas dis qu'il y avais redondance d'info mais si on demande a Drashe un MDC, il ne pourra pas le fournir car les tables sont créés selon les besoins de l'administrateur suivant le nombres de cat qu'il veux.Pour moi une base se doit de comprendre un nombre exact de table pas un nombre variable.
 
PS : si on avais ecouter Merise plus tot on aurait dejà trouve la methode pour afficher les page de topic ou que l'ont soit et sans LIMIT en un tps record depuis longtemp ...(clé imbriqué)

ouais, mais c'est casse couilles pour développer des plugins Winamp qui postent dans le forum

Oui et non : si on veut faire un découpage des infos (pas tout dans le même panier), on est obligé d'utiliser la méthode de tables crées selon le besoin de cats.

Un tel decoupage ne sert a rien si on applique le principe des clés imbriqués ...

explique ?

Bon je réexplique pourquoi j'ai voulu préparer un découpage des infos en plusieurs tables (un groupe de tables par catégorie) :

• Avoir des plus petites tables (plus légères à manipuler).
• Un problème sur une table ne va pas impacter tout le forum mais simplement la cat concernée.
• Limiter voire éviter la redondance d'infos.
• Permettre une possibilité de sauvegarder catégorie par catégorie.
• Limiter le recours à des requêtes avec jointures.

(j'en oublie surement)

+1

J'explique :  
 
Si on crée une clé imbriqué dans la table message tel que la clé primaire aurait pour composition(id_cat,id_forum,id_sujet,id_message).
id_cat est la cle primaire de la table cat et est auto incrementé.
La table forum a pour cle primaire une cle compose de id_cat et id_forum
La table sujet a pour cle primaire une cle compose de id_cat,id_forum et id_sujet
 
id_forum pourra donc avoir plusieurs fois la valeur 1 car la cat 1 aura un forum 1 et la cat 2 aura un forum 1
de meme pour id_sujet et de meme pour id_message qui ne seront pas auto incrementé en consequance.
 
Dans TOUTES les requetes, LIMIT ne sera pas necessaire car les id_sujet et id_message seront croissant pour CHAQUES forum et CHAQUES sujet et on pourra faire une requete du style :  
WHERE id_message > ".($page*$post_par_page)."
AND id_message < ".(($page+1)*$post_par_page)."

avec ça t'auras toujours le problème quand tu veux faire remonter un message ou effacer un message, ben faut refaire tous tes id_message et ça prend du temps

Alors faire remonter un message je ne comprend pas  
 
Et puis supprimer un message tu ne refais pas TOUS les id message mais seulement ceux qui sont superieur a celui qui a été supprimé et qui appartiennenent au meme sujet forum rubrique
->  
UPDATE message  
SET id_message=id_message-1  
WHERE id_message > ".id_delete."
AND id_sujet = ".$id_sujet."
AND id_forum = ".$id_forum."
AND id_rubrique = ".$id_rubrique."
 
Et pour l'histoire du temps ben je ne suis pas d'accord tout simplement sur un petit topic c rapide sur un gros, en general on supprime genre le dernier ou l avant dernier et donc la requete est super rapide aussi et sinon comme je l'ai deja dis plus haut tu verrouille le sujet avant l'UPDATE et tu deverrouille apres l'UPDATE

Ton système me parait non seulement contraignant mais aussi assez lourd. A priori, si tu gère bien ton affaire, tu n'aura pas besoin de te créer une telle ID composée.

 
J'ai hate de savoir comment tu gere bien ton affaire toi ?