Reprise du message précédent :

j'ai jamais dis le contraire, j'utilise également quelque chose de différent du select ... limit x, y
 
Sinon là je lis également quelques livres sur diverses optimisations avec pas mal de maths derrière, ce que je faisais pas avant, j'ai hâte de mettre ca en oeuvre

 
Dichotomie

C'est quoi comme titres de bouquins ? ça peut être intéressant je pense

ou pas
 
Anthomicro: http://www.amazon.co.uk/exec/obido [...] 54-8739117
http://www.amazon.co.uk/exec/obido [...] 54-8739117
http://www.amazon.co.uk/exec/obido [...] 54-8739117
 
tu trouveras des livres très intéressants, j'en ai pas tellement trouvé en francais malheuresement

Merci :-)

une petite question : il est de combien le ratio lectures de pages d'index des topics/ post de contributions ? (un ordre de grandeur suffira)

ça dépend de chaque forum

et toi sur le tiens ?

punBB   (mais php4)

 
Je n'ai pas de stats très précises vu que je suis en mutu, mais c'est au moins du 300:1 (en gros 300 requêtes de lecture pour 1 d'écriture) mais je te donne presque des chiffres au pif là...  

Je m'interroge juste (je n'ai pas assez d'expérience pour avancer des arguments contre la méthode anti-LIMIT)...
 
Mais si à chaque écriture dans un topic on réécrit un champ dans dans tous les topics moins anciens et si à chaque suppression de topic on réécrit un champ dans TOUS les topics du forum, ça fait quand même une charge énorme.
 
Dans le simple test de remplir une table avec des milliers de topics et de chronométrer ce qui est le mieux entre LIMIT et BETWEEN, BETWEEN sera certainement plus rapide comme tu dis. Sauf que sur un forum en état de marche, pendant que tu fais ton BETWEEN, y'aura plein de monde qui lancera des UPDATE à tout va pour renuméroter les id_class et là ça va bien ralentir.
 
La question est donc de savoir à quel point ça ralentit. Tu as sans doute plus d'expérience que moi donc je veux bien te faire confiance mais je m'intéroge quand même.

Non y'aura pas plein de monde (ça dépend du forum encore une fois), mais y'a plus de requêtes de lecture que d'écriture en général , et quand tu fais un update, généralement tu réponds au topic situé en haut (ou sur la première page, ce qui fait allez au pire 20 topics à updater... ça prend que dalle comme temps comparé à un LIMIT (qui lui sélectionne TOUTE la table avant de te retourner les X valeurs, donc si t'as 1000000 de topics bon courage) qui lui va te mettre le serveur à genoux

Ma foi, ça me convainc.

Après j'aimerais bien connaître la technique de joce étant donné que j'ai posté dans le dernier topic blabla et que ça a été très rapide (comme d'hab quoi) pour faire remonter le topic
 
Il doit donc y avoir un truc en plus je pense

et simplement mettre la date du dernier post dans le topic (dénormalisation) ? avec un index bTree dessus, ça fait pas l'effet voulu ? insertion en O(log(n))
 
bon il faut avoir des transactions pour faire ça, mais il me semble que mySQL les a maintenant.

nraynaud > même si c'est déjà fait me concernant, j'ai un index sur la date de dernier post car je m'en sers pour d'autres fonctionnalités, mais c'est largement moins efficace que le BETWEEN qui lui va te retourner seulement les lignes voulues

ben tu fais un order by et un limit, tu es dans les meilleures conditions pour le faire.

non, ORDER BY c'est hyper lent (car il va d'abord faire l'order by puis ensuite le LIMIT) bref t'es dans le pire cas là. De toute façon utiliser LIMIT c'est à proscrire, qu'il y ait des index ou non...

Dis Joce, au lieu de tourner autour du pot, tu veux pas nous filer ta requête pour ne pas utiliser de LIMIT ?  

y'a rien à classer du tout, c'est déjà trié dans l'index. quand au limit, pareil on peut interpoller le rang dans l'arbre.

ba si tu fais un ORDER BY ... LIMIT 200000,30 avec le bon index, faudra quand même que tu parcours les 200000 premiers éléments de l'index.

D'où grosse lenteur
 
The-shadow : j'ai filé une solution possible dans ce topic, après faudrait la solution de Joce pour les UPDATE ^^

Perso, j'ai fais un limit et sur mon forum, lui demander d'aller à la dernière page, même du topic bonjour, qui fait 923 pages (de 20 mes.) ne le ralentit qu'un tout petit peu.

Temps de génération ? config ?
 
Parce que "ralentit un tout petit peu" si ta page met 500 ms à se charger tu verras presque pas la différence que si elle en met 200 (ce qui est déjà beaucoup trop en local).

A priori, faudrait voir avec bcp de connectés
Ceci étant, peut-être qu'avec un système de cache (MySQL), ça limite un peu les soucis niveau perfs

ba moi je viens de faire sur HFR un LIMIT 80000,30 sur un index, ca a pris 7.5s au lieu de 0.01 s

tu peux oublier le query cache pour la liste des topics : la table des topics est tout le temps updater à cause des nombres de vues qui sont updatés à chaque visualisation de topic.

Arf ouais effectivement, j'étais plutôt parti sur les messages à l'intérieur d'un tomic

C'est à peu près ça, 300ms normalement et 450ms la dernière page.
Mais c'est difficile à mesurer réellement, les temps sont de toutes façons trop variable.
La config, je sais pas, c'est ce qu'il y a de moins cher en dédié chez OVH.
Enfin, je ne suis pas de toutes façons un éternel chercheur du ms, du moment que ça mets moins d'une seconde, ça me va.

Qu'en est-il d'un ALTER TABLE ORDER BY sur une table qui comporte 2 champs TINYINT avec quelques millions d'enregistrements ?
 
Ca rame ?

Y'a beaucoup de topics de 80000 messages ?
 
Attention hein, j'ai bien compris que je n'utilisais pas la bonne méthode, mais voilà quoi, j'ai pas envie de me prendre la tête pour gagner quelques ms.

Faut prévoir la possibilité Bon OK, ça n'arrive jms autre part que sur HFR

c'est deux problèmes différents ca

ba disons que quand ca arrive, si t'as pas prévu le coup, ca te ruine tout ton serveur.

Clair, mais bon, j'imagine que sur HFR les tomics à 100.000 messages ne sont pas arrivés du jour au lendemain
 
Pour le ALTER TABLE, t'as une idée du temps que ca pourrait mettre ?

A priori, un index bTree fait l'affaire nan ?

Ouai, t'as raison, faut prévoir le coup...
 
 
 
 
...j'économise déjà pour changer de serveur.  

ba teste sur ton serveur
mais à mon avis, ca doit pas faire que du bien

hein
tu as lu quand j'ai dis que un LIMIT 80000,30 prenait 7.5s sur la liste des topics d'HFR ?

Tu suxxes, j'ai rien d'ouvert, pas de script de flood massif sous la main

c'était la stratégie de Clubic : mauvais plan