Reprise du message précédent :

 
J'essaierais bien mais je ne le connais pas trop et sybase est un de mes amours de jeunesse. Il n'est pas trop gourmand en mémoire?

 
je le connais pas trop non plus, je l'ai utilisé mais je la gerais pas faisant l'appli autour
mais c'est gratuit et j'en ai entendu beaucoup de bien (gizmo l'utilise je crois ici)

C'est Joce et Sly qui foutent la mairde

Voilà, j'ai revu l'architecture des drapeaux. Au final, j'y gagne rien en temps de génération (), mais j'ai réussi à réduire un bloc d'un peu moins de 100 lignes de code en une seule ligne (véridique). Et ça me permet d'avoir un système plus flexible, si jamais l'envie me prend de rajouter un troisième type de drapal, par exemple.
 
Merci Sky

A la base, ca consomme plus en mémoire que MySQL, c'est clair. C'est aussi plus gourmand en ressource pour les petites bases. D'un autre côté, quand ce sont de petites bases, on a pas besoin de beaucoup de ressources. Ce qui est intéressant, c'est que le ratio charge/taille/consomation vire en sa faveur quand on agrandit la taille de l'application. En outre, elle dispose de fonctions supplémentaires (pas forcément utilies pour un forum) vis-à-vis de mysql.
 
En fait, ca dépend de ce que tu veux faire: tu as peu de ressoureces et une petites db, Mysql sera mieux. Pareil si c'est une DB moyenne (quelques giga) et beaucoup de lectures mais peu de modification. Au-delà, je considère vraiment Postgresql comme plus sûr et plus efficace, notamment pour ce qui est de subbir les modification (à condition de savoir s'en servir bien sûr)

si tu test avec 5 drapeau dans la bdd et 10 posts c'est un  peu normal

 
yep, c'est ce que je me disais aussi

 
Merci pour toutes ces explications. Comme Sybase est téléchargeable gratuitement pour le dev, qu'il est très économique en ressources si on le tune correctement, que je le connaissais bien et que c'est une vraie Ferrari bien chiante à entretenir (dont krosoft a fait une petite Mercedes nommée SqlServer), je vais plutôt le choisir. Après, j'essaierai avec d'autres sgbd, Postgresql en tête.

 
Je vois pas l'intérêt de l'enlever

non mais c'est juste que ça le gêne lui

je vois pas non plus l'interet de l'avoir ajouté

Eviter de parasiter google avec des liens sans rapport (ou alors très lointain) avec les mots-clefs?

une question tout à fait à la con : des gros blocs de commentaires (style 100 lignes), ça peut avoir un impact sur le temps de génération d'une page ? (en PHP)

enculage de mouches à mon avis, ça doit être le genre de truc qui doit avoir un impact sur des fichiers PHP du style 100MB

Yep
 
Je viens de voir votre topic, il en est ou le forum Open-source made in toute la team ?
 
Sinon, ya moyen que je vous rejoigne ?

le forum de la team est au point mort  Pas assez de disponibilités
 
salut Yana, ça baigne?

Ca va très bien, on s'était déjà vu sur BlaBla@Prog non ?

en effet

C'était il y a quelques mois
 
Sinon, j'aurais bien aimé vous rejoindre, j'ai plus rien à prog pour le moment, c'est chiant
 
Fin voilà, si jamais vous continuez, pm moi

bin viende sur blabla@prog

heu je voulais savoir combien de personne parmit celle ki on prog leur propre forum forum on 2 table distincte:
une pour les sujets, une pour les réponses ?
sa doit faire gagner en temp de génération sa non ?

ce serait un beau gachis
perso, c'est 2 tables séparées.

j'ai 2 tables séparées, mais le premier post du sujet est stocké dans la table posts et non dans la table de topics (si c'est ce que tu sous entends par une pour les sujets et une pour les réponses):jap:

 
La méthode consistant à tronçonner ainsi ses tables s'appelle le vertical split (découpage vertical). Les accès sur des petites tables sont plus rapides que sur des grosses tables pour les raisons suivantes :
- l'index est d'une taille plus petite et il sera donc plus rapide à lire
- l'index , s'il est sous forme d'un btree, aura moins de niveaux et il sera donc plus rapide à parcourir
- les données sont mieux distribuées sur le disque ce qui accélère leur lecture (encore qu'il y a d'autres méthodes pour faire cela).
 
Si on fait ça bien, on met les données anciennes dans d'autres tables, ce qui permet encore de gagner en performances car on évite ainsi d'avoir un index pollué par des enregistrements auxquels personne n'accède jamais ou presque jamais.
En théorie, il faudrait faire bien plus que deux tables mais n tables, découpées selon un intervalle de temps. L'inconvénient est que c'est un chouillat plus compliqué à programmer correctement. Pour faire plus simple, on peut faire 4 tables, une pour les topics récents, une pour les réponses récentes, une pour les topics anciens, une pour les réponses anciennes. Cela accélère déjà beaucoup les requêtes. Pour ma part, j'ai choisi de faire n tables mais je ne sais pas encore selon quel intervalle.

C'est sur que c'est pas mal ta méthode, mais comment tu fais si quelqu'un répond à un topic qui se trouve dans la table ancien ? Tu redéplaces aussi toutes les réponses à ce topic dans la tables des réponses récentes ?

DocMaboul : je t'avais posé une question à ce sujet et tu n'y as pas répondu, en tronçonnant les tables avec les topics/posts récents et les anciens sur d'autres tables, comment gères tu un mec qui écrit un nouveau message dans un topic qui est ancien ? Ca implique soit de déplacer le topic et ses réponses dans la table récente ( entrainant une charge très conséquente pour le serveur s'il y a un certain nombre de messages genre 3000 posts à bouger ), soit de gérer une requête supplémentaire sur la table plus ancienne dans ce cas, et là c'est 1 requête par table à chaque lecture ce qui est pas mieux voire pire qu'une requête sur une table unique de la taille des 2 tables ( nouveaux + anciens ).
 
A moins d'interdire l'écriture de nouveaux messages dans la table ancienne ( sorte d'archivage donc ), je ne vois pas trop comment tu fais pour ne pas rencontrer des cas critiques avec ta méthode Et pour moi je trouve dommage de condamner un topic uniquement parce qu'il est pas assez récent.  
 
De plus comment gères tu le tronçonnage, par périodes tu purges une partie d'une table dans une autre ? Dans ce cas la purge est assez lourde aussi non ?
 
Franchement vu ce que joce expliquait pour les index sous MySQL ( bon c'est que pour MySQL ok ), je vois pas trop le gain et au contraire j'y vois de gros inconvénients et même des cas critiques
 
Edit : damned I'm grillaid

 
pardon, je n'ai pas percuté.
 

 
Il faut déplacer le topic et ses réponses. Ce n'est pas si lourd que ça a faire. En comparaison du gain de perf, c'est même du pipi de chat. Et d'autant plus que cela n'arrive qu'une fois par période et par (topic, réponses).
 

 
C'est un peu plus chiant à coder, certes, mais c'est pas le bout du monde non plus.
 

 
Non. Il suffit de créer toutes les tables dont on a besoin au départ et ça roule (ou à la limite de créer en fin d'année les tables de l'année suivante). Il faut juste faire un drop des statistiques d'utilisation des tables d'une période lors d'un changement pour éviter que l'optimiseur choisisse des stratégies non-adaptées à ce qui maintenant a plutôt une gueule d'archive.
 

 
Ce que joce expliquait ne concernait que la mémoire et non le parcours d'un index sous une forme de btree. En clair, cela veut probablement dire que mysql cache les chaînons {root-...-leaf} les plus utilisés comme le font la plupart des "gros" sgbd. Ca ne change rien au fait qu'il faut parcourir quand même la chaîne et que plus il y a d'enregistrements, plus l'arbre est profond, et plus c'est long. Si vous ne comprenez pas ce que je vous explique et que vous ne me croyez pas sur parole, faites-vous une table avec 3 000 000 d'enregistrements, quelques milliers de select via un index et faites le même test avec le même index sur une table de 300 000 enregistrements. Vous allez voir s'il n'y a pas un gain de performances... (l'accès à la première table devrait être en quatre et huit fois plus lent)
 
Et ça, c'est sans parler de la distribution des données sur le disque.

 
Ce n'est pas "ma" méthode. C'est très utilisé chez les opérateurs téléphoniques par exemple. S'ils enregistraient tous les tickets d'appel dans la même table, vous ne seriez jamais facturé tellement ce serait long...

 
Là, j'ai dit une connerie. Mais ce sera quand même plus long.

Remarque : 3 000 000 ne suffiront pas pour sentir une grosse différence si on utilise qu'un petit index, comme sur un entier par exemple, et qu'on ne fait que des accès avec une sélection à deux francs sur un mode entier_de_la_clé=constante (par exemple).
 
Pour en savoir un peu plus, ce document est pas mal : http://csdl.computer.org/comp/proc [...] 813013.pdf  
Il consacre un passage entier au découpage vertical et horizontal des tables.

Ok, mais personnellement avec l'expérience sur ce forum, on a constaté que déplacer un gros topic vers une autre table était très lourd en charge. Dans le cas d'un forum très fréquenté ou la charge du serveur est non négligeable, c'est assez pénible de faire une opération de ce genre, il suffit que 2 personnes au même moment fassent un up de vieux topic de plusieurs centaines de pages pour mettre à genou la machine.  
 
C'est très loin d'un pipi de chat, c'est rare d'avoir le cas, mais il est critique.
 
On a eu des déplacements de topics de centaines de pages sur HFR qui ont fait monter de manière énorme la charge du serveur. C'était juste un déplacement d'un topic entre 2 sections et c'est assez équivalent du coup. On peut pas injecter et supprimer des tonnes d'entrées comme ça à la volée en journée de haute fréquentation, c'est trop lourd.
 
A noter également que la majeure partie de la charge sur un serveur web dont la structure SQL et les requêtes sont bien codées se situe quand même souvent dans la partie Apache/PHP, j'ai souvent eu la surprise en passant d'un serveur LAMP à Apache/PHP + MySQL séparés en 2 serveurs de constater que celui pour le SQL se tournait un peu les pouces à côté du serveur web. Pour un cas de très importantes bases comme sur ce forum, ça revient certainement à l'équilibre mais pour moi le principal problème est de faire des requêtes propres sur des bases bien indexées et structurées et aussi d'avoir un code PHP pas trop lourd en lui même.
 
J'avoue que je serais curieux de voir sur HFR ce que ça donnerait un serveur web + un serveur SQL.
 
Reste que je maintiens mon idée que le déplacement d'un paquet important d'entrées entre 2 tables dont celle cible est très sollicitée reste une très mauvaise idée
 
P.S. : Oui j'ai dis une connerie pour l'index, désolé j'étais pas très frais j'ai raconté n'importe quoi

 
Ben en meme temps un opérateur de téléphone c'est pas un forum .... Et puis les tickets d'appels une fois facturés ne vont pas risquer d'être resortis par un utilisateur.
C'est un très bon exemple où le "tronconnage" des données va servir, mais c'est pas du tout adapté au cas d'un forum.

Sly> pourquoi veut tu deplacer le topic de la table ? lors d'un up, ce qui bouge dans l'affichage, c'est le titre du topic et non le contenu du topic.
Suffit de continuer a poster dans cette table. toi tu reflechi comme le systeme de split de l'epoque, une fois qu'on a couper, on peut plus poster dedans. Ben faut pas penser comme ca. faut se dirent "les messages des nouveaux topic vont dans la nouvelle table" et non pas se dire "les nouveaux messages vont dans la nouvelle table".
Ensuite, si tu vois qu'une table contient beaucoup de gros sujet, tu peut toujours deplacer le topic manuellement pendant une heure creuse.
mais bon, aprés c'est assez chiant a gerer.

 
Ca dépend de pas mal de paramètres mais si c'est bien fait, normalement, ce n'est pas si lourd. Je ferai des benchs sur mon vieux serveur et je vous dirai ce que j'obtiens.
 

 
Ca dépend... Avec mon Sybase chéri par exemple, j'ai dans l'api de l'openclient des fonctions pour faire du bulk-copy entre tables. Si ça reste dans la même base, il ne touche pas au texte qui est stocké à part et ne déplace donc que quelques entiers, quelques petites chaines et une ou deux dates. Je ferai des tests avec cette série de fonctions histoire de voir la différence profonde. Et aussi entre Sybase et mysql.
 

 
Je ne voudrais pas être vexant ou faire le troll mais avec du php, ce n'est pas foncièrement étonnant. Je suppose que vous gardez en base les "codes" d'affichage des smileys qui sont donc convertis en url à la volée. Ne serait-ce que ce traitement doit être un gros goulet d'étranglement parce que le mon_string_replace_de_mon_langage_namoi va très probablement faire de très coûteuses réallocations mémoire. Si on veut gagner de la cpu, une première solution est de préallouer ses chaînes en début de traitement mais je ne sais pas si c'est possible avec du php. Une deuxième solution serait de parser soi-même le message et d'envoyer au client ce qui est bon à l'être au fur et à mesure afin d'éviter les allocations. Après, j'ai des doutes sur l'efficience d'un tel parser en php.
 

 
Moi aussi.
 

 
On verra ça aux résultats de ces benchs.
 

 
C'est pas grave. Je franchis aussi plusieurs fois par jour le mur du çon. C'est pas tous les jours facile de voir qu'on devient un bon vieux con...

 
Certes mais prenons l'exemple d'un vieux schnock, directeur de wanadoo par exemple, qui vient vous acheter un forum. Comme c'est un vieux, il en est resté à l'affichage arborescent. Comme c'est un client riche, il est chiant. Il veux avoir sur son mode arborescent une couleur pour les urls des messages déjà lus et une autre pour les urls des messages non-lus. Il veux aussi avoir sur la liste des posts le nombre de messages non-lus dans le fil (et pas juste un simple drapeau). Sur la page d'accueil, il veut la même chose pour ses sections ou ses sous-sections. Potentiellement, il a quelques millions d'utilisateurs pour son forum. Si vous ne splittez pas les tables, vous êtes mort (enfin, surtout le serveur).

DocMaboul> au fait, tu sais que le format de fichiers MyISAM utilisé par MySQL (par défaut, et pour la DB du forum HFR) correspond à ce qu'on appelle couramment un flatfile?
 
nan parce que j'ai l'impression que la méthode de stockage de Sybase (ou même n'importe quel SGBD transactionnel) et MySQL/MyISAM est tout à fait différente

ok d'accord jen demander pas temp bon, alors pour la prochaine version de mon forum je vais coder un bordel avec 2 table une pour les sujets et une pour les réponses merci

 
L'inconvénient de cette méthode est qu'elle oblige potentiellement à aller lire toutes les vieilles tables pour être sûr qu'on affiche bien la liste complète des topics. A moins que je n'aie pas compris ce que vous vouliez dire?

ce que l'on va splitter c'est la table des reponses, et non des topics, donc ca ne genera en rien l'affichage des titres des topics.
 
 
ps: le tutoyement est de rigeurs sur un forum

 
Qui peut le plus peut le moins. Sybase préfère ce que l'on appelle des "raw device" (en clair, on lui donne une partition plutôt qu'un fichier) mais il peut très bien gérer les fichiers plats. Il est juste moins performant et consomme alors un peu plus de ressources. Il me semblait que depuis peu mysql gérait aussi les raw device. Je me trompe?
 
Après, il a de grandes différences entre Sybase et MySql. La plus dure est certainement qu'avec Sybase, il est très facile de planter complètement le serveur (si le dba est un tocard).

 
Rien à voir avec le split
 
C'est pas en temps réel ton truc, c'est lourd quand même. Par contre y'a de l'idée quand même, possible de mettre un champ supplémentaire dans la table de topics pour savoir dans quelle base taper pour le contenu du message, mais dans ce cas les nouveaux messages vont quand même dans l'ancienne table sinon c'est injouable dans l'affichage. Ca reste difficile à équilibrer quand même, à la limite autant faire un au moment de la création un système qui met les réponses du topic dans la table la plus légère parmi l'ensemble de n tables prédéfinies.
 
Ca reste beaucoup de bordel pour en définitive pas grand chose, ça ajoute juste un aiguillage à l'arbre qui lui est dans le code PHP.
 
A voir mais beaucoup de bordel pour un résultat dont je ne suis pas certain