Reprise du message précédent :

pas la peine de me parler avec autant d'arogance      
 
Et est ce bien optimisé ta metode avec gettext?    
car je ne vois pas plus simple et plus leger qu'un tableau contenant les phrases à traduire.

gettext, c'est du compilé, ca gére les pluriels, les différences constructions linguistiques et l'insertions de variables.

Merci, j'y ai jeté un coup d'oeil... le between marche bien, mais le problème est que si 5 posts sont supprimés, il y aura 5 posts de moins sur la page correspondante
 
Un truc qui m'a choqué:

IPB utilise IN (justement, c'est pourquoi je cherche à faire pareil)
Si tu veux vérifier, cherche un forum qui active le debugging, tu verras les requêtes

Ils ont dû changer de méthode depuis, je vais installer IPB et je te dis ensuite
 
EDIT : j'affiche un forum :  
 

 
J'affiche un topic :
 

 
Y'a encore des progrès à faire  

Quelle version ?

C'est lourd, non ?

 
2.1.6 (la 2.1.7 ne corrige que des failles)
 

 
Non car généralement tu n'updates pas beaucoup de topics

Moi pas comprendre    
 
"rubrique", pour toi, c'est "forum" ?

Je viens de vérifier aussi, ça me semblait bien louche qu'ils aient changé.  
Avec une 2.1.4, mêmes requêtes que Anthomicro avec un LIMIT classique. La majorité du forum en V2 est similaire au 1.3 au niveau de la gestion des requêtes SQL, tout le reste autour a été alourdi. Y a bien des requêtes avec un IN() mais c'est pour les attachements par exemple. C'est pas grave, leur système de cache pallie à la lenteur de la requête

 
En parlant d'ipb quand je dis que je consulte un forum oui c'est une rubrique il est vrai que je dis normalement "forum" au sens du terme général, mais bon j'avais voulu reprendre les termes utilisés par IPB.
 

 
Heu    

Ok

Je l'ai sûrement rêvé alors
 
Tu as mieux que LIMIT  (BETWEEN pose problème en cas de suppression) ?
Car récupérer toutes les IDs d'une page et les mettre dans un IN, ça me parait compliqué

Pc_eXPert > Je peux montrer ma méthode si tu veux, c'est implémentable partout sans s'embêter. Personnellement, j'utilise un LIMIT un peu modifié et c'est Joce qui avait suggéré la même chose un peu plus haut dans ce topic. Avec mes tests (IPB 1.3 très nettoyé et modifié), c'est 100-200+% de mieux que le simple LIMIT utilisé par IPB par exemple (+ le topic est gros, + on gagne en fait, même si ça ralentit quand même à force), mais ça repousse ma limite de découpe des topics pour alléger. Le BETWEEN est très intéressant et sera p/e implementé dans le futur, mais c'est effectivement un peu + chiant à gérer surtout avec le DELETE.
 
EDIT : j'ai retrouvé la requête originale pour visualiser les replys dans un topic pour IPB. La requête de base est celle-là :

La mienne (ancienne version) a été nettoyée et j'ai viré ce qu'y ne sert pas par rapport à celle du dessus :

 
Le problème avec cette seule requête, dont la structure est commune à un très grand nombre de forum, c'est que l'ORDER va devoir trier un très gros volume de données (il rapatrie tout ce qui fait référence au topic en question) avant de piocher un certain nombre de données avec le LIMIT. Or ça bouffe un temps fou de faire ça car plus le topic contient de replys, plus le volume à traiter est énorme et plus la requête va morfler.
 
Le but est donc de scinder ça en 2 requêtes + petites et + légères.
 
La 1ère récupére uniquement les ID des replys qu'on doit afficher en utilisant un ORDER et un LIMIT, mais on ne travaille que sur des ID numériques donc le volume a traiter et à ordonner est bien plus faible, la requête va bien plus vite (même si elle reste coûteuse quand le topic enfle beaucoup car la liste d'ID à trier s'allonge...) :

Là où ça différe avec Joce, c'est que moi je ne créé pas une TEMPORARY TABLE pour stocker ces ID et utiliser cette table dans la 2ème requête en temps qu'INDEX (avec un USING() ) car créer une TEMPORARY TABLE ça prend du temps (~0.09 sec sur ma machine locale y me semble sans optis particulières ). Ca ne ramène de toute façon rien d'intéressant de mon point de vue car la méthode de la table temporaire reste toujours plus lente que ce qui suit. Donc je mets tout simplement cette liste d'ID dans une chaîne de caractères entre virgules pour l'injecter dans la 2ème requête, c'est + rapide :

Il ne reste plus qu'à aller chercher toutes les données utiles uniquement des X replys qu'on veut afficher et dont on connait maintenant les ID. On n'a plus rien à trier ou à piocher puisque la liste d'ID est déjà dans l'ordre choisi, la 2ème requête est quasi instantanée ici, la + gourmande est de très loin la 1ère (95% du temps total d'éxécution des 2 requêtes présentées). J'utilise un IN() pour ne piocher que ce qui m'intéresse dans la table des replys (les ID ne se suivent pas donc pas de BETWEEN possible...). Attention aussi à faire un test sur le contenu qu'on envoit au IN() car s'il la chaîne est vide, MySQL renvoit une erreur, normal... Donc là si la chaine est vide, c'est qu'on vient de DELETE le dernier reply de la page en cours, on fait donc un saut pour aller chercher la routine d'affichage du dernier reply du topic. La 2ème requête qui va chercher les data pour l'affichage :

Au final, j'y gagne nettement en temps de génération et la différence se voit bien (test jusqu'à 200000 replys dans un seul topic) ! Alors oui on a 2 requêtes au lieu d'1, mais on bouffe bien moins de ressources globalement. Donc en attendant de passer à une méthode + optimisée @la BETWEEN par exemple (ou un autre truc à définir suivant les différents problèmes que ça engendre), ça en restera là pour l'instant pour moi. On fait un SPLIT des gros topics à 1000 pages environ à la main car les énormes topics ne sont pas légion dans mon cas et ça ne pose aucun souci

Merci ça semble efficace.. Je vais essayer de l'implémenter (si je trouve une solution avec le between, MP)
 
Merci encore

C'est toujours mieux que rien en effet

Rosco> Ta solution fonctionne Il faut par contre utiliser mysql_fetch_array() (ou assoc()) à la place de mysql_fetch_row(), puisque tu utilises la valeur associative dans ta variable(array) $row
 
Nota: je suis pas HS, je code ma board ( ) IPB est juste une source d'inspiration parmi tant d'autres, c'est tout
 
Merci à vous en tout cas

T'as fais des tests comparatifs ?

Alors avec vos histoire de non utilisation de limit, ça m'a donné envie d'améliorer mon bouzin ^^
 
Je vous le montre dés que il devient montrable
En tout cas je gagne déjà 3ms sur un topic qui en met 24 à l'origine ^^
 
Anthomicro, la premiere fois que j'ai refait le code de mon forum pour l'optimiser, c'était grace à ton tuto sur phpnet (hébergeur php merdique)
http://www.phpnet.org/forum/index. [...] 975.0.html D'ailleur j'adore ta signature sur ce forum

Même pas la peine de chercher un temps en secondes précis: on le voit de suite
J'ai fait une loop pour avoir ~15 000 pages (:D) et y'a pas photo: la seconde solution (IN) est largement plus rapide
Mais quand même: 8,601 s de moyenne (15 essais) avec le IN, 14,679 s de moyenne avec Limit (15 essais)
 
Par contre j'ai pas compris l'utilisation mémoire du serveur: 285376 avec le limit contre 288048 avec IN (fonction memory_get_usage())
 
Sinon je réfléchis à une autre solution pour se débarasser définitivement du LIMIT. Si je trouve une solution fonctionnelle mais surtout interessante niveau perfs, il est évident que je vous en ferez part

Chez moi, le ratio entre le temps pour IN() et celui pour LIMIT atteignait 3 pour 200000 messages. J'ai pas vérifié au niveau mémoire ce que ça engendrait chez moi, jamais regardé ces fonctions de toute façon. T'es sûr que ça représente uniquement le "poids" de la requête et pas une utilisation + globale avec des choses qui restent en mémoire (variables détruites en fin de requête pour faire de la place ?). A vue de nez, la 2ème soluce devrait pourtant être un peu + légère , faudrait voir en interne comment MySQL gère ce dont il a besoin dans les 2 cas...

En effet, je prends en compte le temps de chargement intégral de la page, et pas uniquement la requête
De plus, ça varie entre 5 et 10 pour le IN selon les refresh (serveur local un peu fatigué).
 
edit: d'ailleurs, pourrais-tu me dire comment calculer uniquement le temps d'éxecution de la requête sql ? (là j'ai utilisé le classique microtime())

D'ailleurs la fonction pour la mémoire c'est pour voir ce que PHP pompe en un temps donné donc le poids des variables notamment, pas pour MySQL durant son traitement (et là ça devrait être + léger avec le IN()). C'est donc normal d'avoir quasi la même chose puisque le résultat final est identique au niveau de ce que contiennent les variables.  
Mon ratio c'est aussi le temps de génération total de la page, mais ça se retrouvait en faisant les requêtes à la main aussi (dans phpmyadmin, y donne le temps directement).

ok ok
 
J'en suis à 4,947 s contre 40,116 s pour 43009 pages  
 Apparemment, le gain est exponentiellement fonction du nombre de pages
Mais là, la différence me parait énorme. (bon aussi le limit doit traiter 43K+ pages donc bon)
 
Bref c'est mieux anyway...
 
 
et OK pour la mémoire

 
Oui le censeur de PHPPROUT (Thibaud et Alex le boulet aussi) m'ont bannis plusieurs fois les nazes ^^ donc bon j'ai changé ma signature (chose encore possible) mais ils n'ont toujours pas grillé    
 
Bref sinon pour le tuto mieux vaut suivre le nouveau que j'ai fait sur vulgarisation intitulé "optimiser MySQL". C'est plus détaillé et plus juste

Oui c'est ce que j'avais précisé, le volume de données dans les 2 cas n'augmentent pas de la même manière, celui du 2ème cas augmente "très doucement". Mais bon 4 s c'est mieux que 40 c'est sûr, mais ça reste beaucoup trop en "production" si jamais on a des gros topics (faut bien voir qu'il n'y aura pas qu'une seule requête à la fois sur un vrai forum). Vivement un BETWEEN à 0.1-0.2 s tout le temps quelle que soit la page

 
Avec IPB c'est pas demain la veille  

Dans le cas ou MYSQL fait bien son boulot et que les enregistrements sont bien fais l'un aprés l'autre, on doit pouvoir faire sauter le ORDER BY qui visiblement est le seul ralentissement de la requète non ?
D'ailleur pourquoi il arrive que mysql enregistre en vrac des fois ?

Oui le ORDER plombe bien (suffit de le virer pour le voir), mais sans ça, ça arrive dans n'importe quel ordre (ordre qui peut d'ailleurs être changé par l'utilisateur sur certains forums s'il en a envie...). C'est un peu con mais c'est comme ça. Je ne sais pas quel critère "automatique" est pris par Mysql pour rapatrier sans le ORDER, c'est pas aléatoire car le résultat final est toujours le même. Y a forcément un ordre d'arrivée préférentiel dans son truc, mais je ne trouve pas de logique spécifique dans ce que j'ai pu testé en comparant ce qu'il rapatrie. Le LIMIT a aussi une bonne part de responsabilité dans le temps mis par la requête (on voit bien la différence de temps qui grimpe entre la 1ère page et la dernière page sans le ORDER, juste avec un LIMIT) et donc la conjonction des 2 donne un truc infâme    
 
Tu nous présentes quand ta méthode Scull ?
 
D'ailleurs j'ai aussi vu dans le post 1 que Max Evans, qui ne poste plus depuis des années dans ce topic, utilise surement une très bonne méthode car en faisant le tour de son forum Liteboard, les gros topics sont quasi instantanés comme ici (500 pages)...

Ouais pour ça il faudrait d'abord récupérer les IDs manquantes et ajouter d'autant la fin du Between (ça doit pouvoir se faire, quand même)

Déjà dit que j'utilisais pas IPB
Je prends des idées sur IPB

Une petite idée d'optim en passant, elle pose quelques contraintes mais supportables :
 
- On limite les possibilités qu'a le choix de l'utilisateur en terme de nombre de posts par page, par exemple 10, 20, 50. L'important étant que le nombre minimal ne soit pas trop-faible (plus il est gros, plus grand sera le gain ) et que les autres soient des multiples de celui-ci.
 
- On rajoute un champ dans la table des messages nommées "Page", qui stoque donc le numéro de la page. (on garde evidemment toujours un id de message dans le topic)
 
- Quand quelqu'un utilise le nombre de post par page minimal, il suffit de rapattrier les posts qui ont comme n° de page celui demandé, puis de trier par id de message. ( récupération sans tri de 10 messages, puis tri de ceux-ci, une opération rapide )
 
- Quand quelqu'un utilise un nombre de posts par page supérieur (par exemple 50), on demande les posts dont le champ Page est entre n/5 et n/5+5, puis on les trie. ( pareil que le précedent, ca reste aussi rapide )
 
Le truc un peu plus dur c'est quand on supprime un message, mais la, rien de vraiment dramatique. On décrémente le champ Page de tout les messages qui sont les premiers avec une certaine valeur de champ page (l'id de message le plus petit pour chaque groupe de posts ayant la même valeur de Page) seulement dans le cas ou le champ page est supérieur à la valeur du message supprimé. Soit traduit en langage humain (parceque je me doute que c'est pas forcément super compréhensible :
  On déplace chaque 1er post de chaque page vers la page précédente, ou il sera automatiquement dernier à cause de son id de message.
 
En fait on ne met a jour que 1/10 des messages que l'on aurait mis à jour lors d'un redécallage des id si on utilisait la méthode BETWEEN+id consécutifs. c'est pour ca que je disais que le nombre de messages par page influe directement sur les performances de la suppression de messages.
 
C'est pas une méthode superclasse parceque asymptotiquement aussi mauvaise que le BETWEEN, mais en pratique on est dans le monde réel et les topics sont pas -si- énormes que ca, sans compter que l'on supprime rarement les vieux messages, diviser par 10 le cout de l'opération n'est pas négligeable il me semble. Par contre sur l'acces à une page quelconque, le temps est constant quelque-soit la page et le nombre de page
 
Maintenant y'a une bonne nouvelle, je vous ai mentit, il reste encore une optimisation à faire sur cette idée, et l'on peut gagner bcp plus sur le temps de suppression en perdant très peu sur le temps d'accès à une page...

 
Justement je suis dessus    
Et je suis en train de voir comment faire un mix avec ta technique. Tout cela ce concentre surtout sur l'amélioration de ta première requete

0x90 > Je trouve ta méthode compliquée tout de même car t'as plusieurs cas différents à gérer suivant les options user, c'est pas top pratique. Et puis dans le cas d'un multi-DELETE simultané de X replys, t'es un peu embêté car faut pouvoir le gérer aussi.
 
Scull > Ah, j'attends car c'est la + critique et on pense pas forcément à tout  

Heu le forum de liteboard il fait des trucs bizarres au niveau des temps de génération...
Je vous jure ! Promenez vous un peu dans le topic flood de liteboard...

 
 
Non y'a pas plusieurs cas, le 1er est un cas particulier du second, si tu veut la règle générale, il faut que le champ page soit égal a n/x+x ou x=nb de post par page de l'utilisateur divisé par nb de post par page minimal. Dans le cas n°1, x égal 1
 
Par contre, oui le multi-delete simultané peut-être compliqué, mais on parle alors d'une opération vraiment très rare dans un forum (genre ban d'un posteur + suppression de ses messages). Puis y'a pas de miracle, c'est pas les solutions les plus simples qui permettront de gagner du temps

Exact, les toutes dernières pages sont les plus rapide de toutes, si on remonte vers le début du topic le temps de génération augmente un peu. Dans ce topic, y avait qqu'un qui parlait d'une méthode utilisant une symétrie au niveau du LIMIT quand on dépassait la milieu d'un topic, il utilisait une sorte de "LIMIT négatif" ou je sais plus quoi pour partir de la fin des ID sans avoir à parcourir les 50000 avant. C'est peut être un truc dans le genre   . Hum en fait le tps Mysql me parait bien faible, y aurait pas du cache là derrière ?

Overgrilled    

Présente toujours, c'était que du blabla si je me souviens bien, y avait rien de bien concret

J'ai pas encore bien fini mon truc, mais en gros je fais promener un "id" dans les urls pour limiter le nombre de topic à sélectionner...
Sinon j'ai penser à améliorer ton système de deux requètes en... 3 requètes  
Je voix pas ou est le soucis du moment que c'est plus rapide qu'avec une seule
 
 
Le truc en fait c'est d'avoir des réponses "marqueur" dans la liste des réponses.
Par exemple toutes les 500 réponses on met une réponse "normale" mais avec un champs différent. (parce exemple pour moi j'ai un champs valider : 1=ok, 0=poubelle; alors disons 2=marqueur).
 

 
 
Et donc rapidement, on fait une première requete qui en fonction du numéro de la page trouve la l'id de la réponse marqueur la plus proche (floor bien sûr).  
 

 
Ensuite on sort l'id et on limite les dégats du ORDER BY  

 
Tiens d'ailleur en y pensant ? pourquoi pas faire un marqueur toutes les 5000 réponses ? avec un valider à 3 ? et une quatrieme requete ?  

t as remarqué aussi ?
meme un tout petit id en local me prend 100 fois plus de temps

oups edit foireux