Reprise du message précédent :

Ah oui, j'y avait pas pensé
On peux toujours faire une limitation dans le niveaux et ça devrait fonctionner pas mal.

Sur vos forums, vous gérez les drapals ?
Si oui, vous avez mis une limitation par user ?

Pas encore de drapals chez moi, juste une information pour dire si il y a des nouveaux sujets depuis la dernière visite

 
Oki
 
Parce que perso, je gere les drapals, mais j'ai pas mis de limitation, et en mettre une, ca me parait fastidieux

en effet, ça peut être fastidieux, mais comparé à l'espace que tu pourrais gagner , imagine ce forum sans limitation dans les drapeaux, ça doit être quelquechose

 
Oué, c'est vrai
J'vais voir alors, si le forum devient grand, sinon nan

Non que les vues/non vues en fait.
 
Et non, j'ai pas mis de limitation : 150 sujets, 35 membres mais seulement une 10aine d'actifs.

Temps de génération stabilisé à 20 ms pour moi, que je demande la page une ou la page 950. Je n'ai pas fait de base de test avec 4000 pages de topics mais ca ne changerait rien, qu'il y en ait 4000 ou 20 000 d'ailleurs Mon modèle de données est concu pour

 
Et tu as des astuces ? Des index bien placés, etc ?

c'est koi ta requete? combien d'enregistrement ?

Tout est une question d'index effectivement. Sans index les taux de génération de pages sont multipliés par 40
 

La requête n'a rien d'intéressant, un simple SELECT avec 2 jointures, l'une pour récupérer les flags, l'autre pour récupérer les pseudos des posteurs. Au niveau des enregistrements, 8.3 millions pour le forum dont 99 000 pour la table des sujets.

 
Ha oué pas mal    

pour mettre un texte en gras vous utilisez un truc du style :
 
$texte = preg_replace('/(\[g\])(.*?)(\[\/g\])/', '<span style=\"font-weight:bold\">$2</span>', $texte);
 
mais comment faire le remplacement sur plusieurs lignes, je m'explique :
 
[g ] texte [/g] sera mis en gras
 
[g ]texte
 
texte[/g] ne sera pas mis en gras
 
quel est le caractere a specifier en + pour prendre en compte le texte sur plusieurs lignes ? je suis plus habitué avec les eregi_replace, mais les preg_replace sont plus rapides...

 
moi j'utilise un ereg_replace tout con, qui remplace les balises ubb style [b] par <b> mais seulement à l'affichage de la page, dans la base de donnée tout les textes sont formatés avec des balises ubb

Pour avoir de meilleures performances, tu devrait stocker dans la base au format HTML

pour le moment j'utilise aussi un eregi_replace a l'affichage egalement, mais bon j'aurais bien aimer savoir avec preg_replace

 
ouais j'y ai songer mais quand je consulte directement les threads dans la DB, c franchement illisible  

C'est pas un problème ça

moué bof,c'est negligeable le temps que tu va gagner.

 
non il n'a pas tort,  
 
si tu met ton ereg_replace au moment du stockage en DB tu fait le calcul 1 fois
 
alors que si tu le fait à la lecture, tu le fait à chaque regeneration de la page

il y avait aussi la solution de generer une page grace a la bdd. Puis on regarde la page générée.  
Resultat => reunit tous les avantages des parsing avant/apres
un peu chiant a mettre en place et pas tres souple d'utilisation
un peu lourd niveau poids

on appelle ça du cache, mais pour un forum, je suis pas sûr que celà soit très approprié

clair
 
j'ai trouvé une bidouille pour l'histoire des pages n°500 000...
Attention, c'est du bricolage hein :
 
a partir du milieu ( 250 000 ), on trie en asc, mais on prend le limit opposé.
ex:
la table post a 200 000 lignes. on prend 20 posts par page.
Il y a donc 10 000 pages.  
A partir de 5 000 pages, la requete n'est plus :  
SELECT * FROM posts ORDER BY id ( ou date ) DESC LIMIT 150 000,20
mais :
SELECT * FROM posts ORDER BY id ASC LIMIT 200 000-150 000,20
 
ca donne les memes lignes mais dans un ordre inversé.
 
Pour avoir ce resultat, sous phpmyadmin, je divise le tps d'execution par 100 ...
 
 
Apres, il faut faire un arsort() en php.  
Le resultat sera quand meme bien meilleur apres le arsort().
 
Le probleme, c'est que dans la pratique, le arsort(), je vois pas ou le mettre. j'ai testé, et il a pas l'air d'aimer.
Les pages les plus lentes seront donc au milieu.
 
 
ca reste du bricolage

c'est pour quoi faire le asort ? ca sert a rien.
Quand tu fait ta boucle tu parcoure ton tableau a l'envers en comment ton tableau par $i=20; au lieu de i=0; et tu fait i--;

c'est vrai, j'avais meme pas eu l'idee
 
 
vais continuer les tests cette aprem

j'ai du mal a comprendre un truc.
 
$row = mysql_fetch_array($res);
 
j'ai une colonne 'cid'.  
Comment est nommé la valeur 'cid' de la premiere ligne ? $row['cid'][0] ? bah non, ca marche pas

Je tiens à vous remercier pour la technique de la table au format 'Heap', j'ai fais les modifs nécessaires dans ma base de données pour gérer la liste des connectés dans une table à ce format.
 
Du coup même si j'ai besoin de 3 requêtes pour gérer la liste des connectés, c'est plus rapide que 2 requêtes effectuées sur une table au format "normal"

comment vous faites pour obtenir la liste des users connecté au forum ??    
 
j'ai pas encore implementé cette fonction

tu regarde de quand date la dernière action d'un user (tu mets à jour cette date à chaque consultation d'une page), tu défini une préiode pendant laquelle tu considère le user comme actif.
 
Dans mon cas, une user est défini comme connecté s'il a effectué une action dans les 3 dernières minutes

 
ah ouais ok, je comprends  
 
Merci  

et là voici avec une jointure pour savoir si un pseudo est connecté , la jointure se fait avec ma nouvelle table de pseudos connectés au format Heap :

et t'es sur que ta requete est optimisé ?
 

Oh que oui, j'ai encore gagné 10% de temps d'exécution

Bon aller, moi aussi je me lance dans la présentation de mon logiciel de mon logiciel de forum Pour l'instant je me suis uniquement attaché à optimiser sa rapidité. L'aspect graphique a été laissé de côté, et les pages sont simplement HTML 4.01 Compliant (passage en XHTML / Full CSS prévu pour fin 2003/début 2004). Pour ses points fort :
 
- Interface sobre et fonctionnelle
- URL optimisées pour le référencement dans les moteurs de recherche
- Système de "drapeaux" et affichage en temps réel du statut des membres dans les messages (connecté, offline ...)
- Système avancé de détection et de gestion des multinicks
 
Et surtout :
 
- Rapide
- Peut gérer des millions de messages et de sujets sans aucune perte de performance !
- Affiche avec une vitesse constante les premières pages d'un forum / d'un sujet aussi bien que les dernières
- Peut gérer un nombre important de connectés même sur des machines modestes
- Moteur concu pour tourner nickel même sur du mutualisé avec un max_user_connexion faible
- Entièrement compatible MySQL 3.23 (optimisations spécifiques à MySQL 4 à venir !)
 
Le tout est basé sur un modèle de donné propre et portable, qui se suffit à lui même pour arriver au niveau de rapidité actuel. Je n'ai pas eu besoin de découper les sujets en plusieurs parties (les topics de plus de 200 000 messages ne lui font pas peur, cf. Bistrot) ou de créer une table par catégorie pour limiter l'impact de la taille des tables sur les performances
 
Pour voir ce que ca donne le mieux est encore d'aller le voir sur le principal forum où il est utilisé :
 
http://www.forum-auto.com/sqlforum

core 666 > quelle est la config de ton serveur où est le forum ? il est seul ou le site est avec ?

ha ben alors la je suis le cul    
 
felicition et respect
 
vraiment rapide et leger et sobre, comme je les aimes
 
c'est ton site ?

C'est un simple serveur dédié P4 (avec un peu de RAM quand même : 1 Go, ce qui aide bien quand il y a 400 connectés dessus ) Le forum est seul dessus.

OK, ça aide  
 
D'ailleurs faudra que je tente de mettre mon forum sur un serveur équivalent

Sur notre céléron 1.7Ghz, on a déjà eu 1200 onlines

La façon dont tu as géré tes URL nécessite une configuration particulière du serveur quand même ?
On peut donc pas l'installer n'importe où ?

c'est juste de l'url rewriting, on peut le faire avec les .htaccess