Appréciation du bon nombre de requetes mysql ...

[Zecat]

Comme c'est mon premier site avec Mysql, je manque un peu de points de repère sur le bon ou mauvais usage des requêtes mysql sur chaque page ... J'ai donc mis en place un petit compteur (mis a 0 en init session donc en tout debut de page) et avec +1 a chaque requête mysql executée.

Le verdict sur les pages les plus importantes :

Page home du site : 6 (+ 1 optionnelle)
Page home du forum (liste des forums) : 5 (+ 1 optionnelle)
Page liste des topics : 2 (+ 1 optionnelle)
Page liste des messages : 3 (+ 1 optionnelle)

J'ai traqué tout ce que j'ai pu en travaillant au maximum en "array processing" mais là je dois pas être loin du mini (peut etre 1 requete a gratter sur chaque page home au mieux).

Ca vous inspire quoi ? Honnête ou 6 et 5 c'est trop ?

Note : le +1 optionnelle c'est une requete liée au suivi de "qui est en ligne" et elle est optionnelle parce que déclenchée avec un temps de latence de 15 s pour alléger ... En gros, je signale l'arrivée d'un nouveau visteur immediatement à la bdd mais je ne confirme à la bdd la présence d'un visiteur que toutes les 15 secondes (même si il affiche 4 pages durant ces 15 secondes).

 

[finstreet]

Ca peut être énorme comme très très peu. Tout dépend des pages. Perso je sais que je suis très largement au dessus de ça pour les pages qui ne sont pas en cache

 

[YoyoS]

Oublie pas que certaines requêtes ne seront exécutées qu'une fois tous les X temps car tu peux créer un cache à la première exécution puis n'afficher que le cache partout !

cf : le topic de fandecine qui est pas mal pour débuter . Sinon le nombre de requêtes est bon, après faut voir la complexité et rapidité d'execution. Si tu peux augmenter le nombre de requête et diminuer la charge c'est mieux ^^. Nombreux sont les cas où une grosse requête avec table temporaire et tout le brol est bien moins efficace que 2 requêtes (+le reste en php)!

Fais aussi des benchmarks en + du nombre de requêtes par page,tu affiches le temps total que ta page a mis pour être générée (et pas affichée) histoire de comparer.

 

[Zecat]

1 - La on parle de page pas en cache bien sur ...

2 - Ce ne sont que des requetes ultra simples (un champ = une valeur) ou (un champs timestamp > une valeur) et qui retournent à chaque fois un seul champs "datas". Aucun truc lourd style jointure etc etc. Bon je vais coller un microtimedeb et fin pour mesurer aussi le temps ...

3 - sur la différence entre une grosse et n petites, c'est deja fait et j'ai comparé entre :

- 6 petites requetes (champs = aaabbb) puis (champs = aaaccc) etc etc et
- une seul (champ = aaa%) et derriere un foreach et switch pour eclater dans 6 tableaux

et c'est la seconde formule qui gagne dans mon cas. Pas mesuré unitairement mais constaté sur la mesure globale de la page.

 

[Zecat]

Bon finalement j'ai gratouillé un peu et réussi a regrouper des trucs et ca donne :

Page home du site : 4
Page home du forum (liste des forums) : 3 (*)
Page liste des topics : 2
Page liste des messages : 3

Plus la +1 optionnelle. Là je crois que je suis au max coté grattage :mrgreen:

(*)
Une requete pour chopper la liste des forums
Une requete pour chopper la liste des derniers topics
Une requete pour chopper les stats du bloc "qui est en ligne"

 

[e-kiwi]

à terme, il ne doit y avoir aucune requête en partie publique. seule une requête déférée en ajax peut compter les hits. tout le reste doit être généré. le site doit s'afficher sans erreur, même en cas de BDD hors service.
avant d'y arriver, il faut juste que le site tienne et soit fluide. dès que cela ralenti, il faut mettre en cache petit à petit. mais pas de nombre précis (une requête peut prendre 0.001s comme 10s)

 

[Zecat]

OUi oui maintenant que coté nombre je suis au plancher, je vais aller coller des micro time pour mesurer le temps précis pris par les requetes ... histoire d'y voir bien clair et effectivement ensuite la gestion du cache (ne serait ce que pour être solide meme si bdd out un moment).

 

[jcaron]

Le point important c'est surtout que toutes tes requêtes soient correctement optimisées (i.e. utilisent un index adapté).

Jacques.

 

[Zecat]

Petite question à 10 balles kiwi ...

Pour un forum, la mise en cache ne devrait concerner que les visiteurs non membres (et les bots) puisque si visiteurs inscrits, chacun a une visibilité spécifique en fonction de ses préférences d'une part mais aussi de ses autorisations (par exemple des boutons de gestion qui varient par définition comme le bouton editer d'un topic etc) ?

Donc ca limite sérieusement l'aspect "ok meme si bdd out" ou j'ai sauté une marche ?

 

[e-kiwi]

lors de l'identification, toutes ses infos sont mis en session, donc une requête au moment de l'identification, puis basta

 

[finstreet]

Y'a toujours la possibilité de bloquer l'accès membre pendant que la base de données a sauté

 

[Zecat]

Le point important c'est surtout que toutes tes requêtes soient correctement optimisées (i.e. utilisent un index adapté).

Jacques.

index adapaté ?

- Index je vois
- C'est le "adapté" ou je pige pas ce que tu veux dire ...

Mon cas classique c'est :

cle : alpha 6 indexé
datas : texte

et ma recherche c'est cle like "toto". Bref du basique de chez basique. Dans d'autres cas, la cle sera un timestamp mais sinon ensuite idem.

 

[Zecat]

Y'a toujours la possibilité de bloquer l'accès membre pendant que la base de données a sauté

Nous sommes d'accord ... :wink: Et finalement apres analyse, dans le cas d'un forum, la mise en cache ne concerne que les pages "topic" ... en effet toutes les autres sont tellement mouvantes (ne serait-ce que les colonnes nombres et derniers messages) que la durée de vie effective du cache sera ridicule et on passerait plus de temps a mettre a jour le cache qu'a l'exploiter :roll: Sauf a accepter d'afficher une info fausse durant un certains laps de temps :roll:

 

[finstreet]

pour le index adapté, c'est que l'index n'est pas forcément que sur le numéro d'id mais surtout sur les champs où sont faits les recherches. Si tu cherches par nombre de posts par exemple, indexer le champ : Nombre de posts sera plus utile que d'indexer l'id unique de chaque membre. Exemple.

 

[YoyoS]

Note aussi que le cache des topics ne doit avoir aucune limite d'expiration. Il sera juste renouvelé quand il y aura une modification dans le topic.

 

[Zecat]

pour le index adapté, c'est que l'index n'est pas forcément que sur le numéro d'id mais surtout sur les champs où sont faits les recherches. Si tu cherches par nombre de posts par exemple, indexer le champ : Nombre de posts sera plus utile que d'indexer l'id unique de chaque membre. Exemple.

Ca me parait une evidence ... pour moi recherche sur champ implique champs indexé ... c'était le mot adapté ou je tiltais (pensant que ca sous entendait que l'on pouvait/devait générer des index selon des paramètrages différents comme c'ets le cas dans certaines bdd (avec des index priorité recherche, priorité update, priorité ajouts etc qui sont organisés en conséquence avec des filler et zone overflow plus ou moins nombreuses ...).)

 

[Zecat]

Note aussi que le cache des topics ne doit avoir aucune limite d'expiration. Il sera juste renouvelé quand il y aura une modification dans le topic.

Oui bien sûr ... ou dans la date $last_modif_page (une variable chargée en debut de page et qui dit : "je viens de modifier cette page (le script)" (donc le cache est obsolète) :wink: