Priorité de requetes

[LynxEyes]

Bonjour @ tous,

j'espère que vous pourrez m'aider car j'ai soucis avec un de mes sites.

Situation :
Les données sont telles que j'ai mise en place un système de cache (memcache).
Et pour gérer la mise à jour de mes données en cache j'utilise ma crontab pour vérifier que les dates de mise à jour de certains champs n'est pas plus récent que la version de mon cache (info aussi en base)
Donc je fais 2 jointures sur une table de 250.000 lignes qui dure environ 8 secondes pour me retourner les ID des caches a régénérer.

Problème :
Mon soucis c'est que la requête en question semble prioritaire et que pendant son exécution les visiteurs attendent en ce demandant ce qu'il se passe.

Le temps d'exécution de cette requête ne me gène pas plus que ça vu qu'elle tourne en tache de fond. Mais je voudrais faire en sorte qu'elle ne soit prioritaire sur aucune autre requête... Il me semble que c'était possible.

Mes tables sont en InnoDB avec des champs "integer" indexés pour les dates (unix_datetime) que l'on compare.

Exemple du type de requête :

Code :

1
2
3
4
5
SELECT tab_prod.id 
FROM tab_prod_to_image
INNER JOIN tab_image ON tab_prod_to_image.id_image = tab_image.id
INNER JOIN tab_prod ON tab_prod_to_image.id_fiche = tab_prod.id_fiche
WHERE tab_image.date_modif > tab_prod.cache_date

Merci d'avance pour votre temps (et vos conseils)

[CinePhil]

8 secondes pour exécuter ta requête avec seulement 250 000 lignes, ce n'est pas normal !
Tes tables sont-elles correctement indexées ?

[LynxEyes]

Oui pas de soucis sur l'indexation de mes tables.

C'est pas une table de 250.000 lignes mais une jointure entre 3 tables d'au moins 250.000 lignes chacune, joint sur une clé.

Cette requête est optimisé à son extrême, et je ne pense pas qu'on puisse faire mieux.
Le système assez ancien y est sûrement aussi pour beaucoup mais n'est pas non plus changeable.

Ce que je voudrais surtout c'est que la requête ne ralentisse pas les autres.
J'ai d'autre requête qui me pose le même soucis. Je voudrais qu'elles soient "non-prioritaires".
J'ai vu des choses pour définir certaines priorités dans l’exécution mais rien pour baisser la priorité.

Avez-vous une idée ?

[CinePhil]

Même avec 3 tables de 250 000 lignes, ça fait quand même long !

On peut avoir le résultat de EXPLAIN ta requête ?

[Yanika_bzh]

Vous pouvez toujours regarder du coté du HIGH_PRIORITY
Mais comme CinePhil, je pense que 8 secondes pour une requete avec une jointure, cela me parait anormal... (Indexes, condition de restriction, ... )
Vous pouvez poster un plan d'execution, juste pour information ?

Bon courage

[LynxEyes]

Un petit explain :

Code :

1
2
3
4
5
6
7
+----+-------------+-------------------------+------+---------------------------+----------+---------+----------------------------------------+--------+-------------+
| id | select_type | TABLE                   | type | possible_keys             | KEY      | key_len | ref                                    | rows   | Extra       |
+----+-------------+-------------------------+------+---------------------------+----------+---------+----------------------------------------+--------+-------------+
|  1 | SIMPLE      | tab_prod_to_image       | ALL  | id_fiche,id,id_copy       | NULL     | NULL    | NULL                                   | 114538 |             |
|  1 | SIMPLE      | tab_image               | ref  | id                        | id       | 4       | db_test.tab_prod_to_image.id           |      1 |             |
|  1 | SIMPLE      | tab_prod                | ref  | id,cache_date             | id       | 4       | db_test.tab_prod_to_image.id_fiche     |      1 | USING WHERE |
+----+-------------+-------------------------+------+---------------------------+----------+---------+----------------------------------------+--------+-------------+

Vous pouvez toujours regarder du coté du HIGH_PRIORITY

En fait, je cherche justement à faire l'inverse de cette fonction...
Je veux que les 500 ou 1000 autres requêtes possibles soient prioritaire sur celle là. Je restais persuadé que c'était possible avec un truc comme :
SELECT LOW_PRIORITY xxx ...
mais je trouve pas.

Vous pouvez poster un plan d'execution, juste pour information ?

C'est à dire ?

Merci pour vos réponses

[Yanika_bzh]

Vous n'avez pas d'index sur la colonne date_modif de la table tab_image ?

[LynxEyes]

Si si, le champs est bien indexé

[CinePhil]

Envoyé par LynxEyes

Si si, le champs est bien indexé

On ne le voit pas dans l'EXPLAIN !

Par contre, on voit qu'il n'y a que 114 538 lignes de parcourues, ce qui devrait être très rapide.

As-tu essayé de lancer la requête directement dans une console MySQL ou sur phpMyAdmin ? Le résultat devrait apparaître quasi immédiatement. Si ça dure quand même 8 secondes, c'est que ton serveur sature. Si c'est immédiat par ce canal, c'est que la lenteur vient d'ailleurs.

[LynxEyes]

On ne le voit pas dans l'EXPLAIN !

On devrait ? alors qu'elle est dans le where ?
Je viens de vérifier elle y est.

En local elle dure 2.4 sec
Sur le serveur quadri-core de test à peu prêt autant
Mais chez le client : entre 6 et 8 sec

Elle pourrait durer 15 secondes ça ne me générait pas plus que ça... Ce qui est important c'est qu'elle ne mette pas les autres en attente => d'où la question : comment faire pour la dé-prioritarisé (<= super le mot) la requête ?

PS : en local j'utilise SQL_NO_CACHE pour vérifier que mysql ne prend pas le cache et voir les "vrais" perfs.

[CinePhil]

Envoyé par LynxEyes

On devrait ? alors qu'elle est dans le where ?
Je viens de vérifier elle y est.

Ce qu'on ne voit pas c'est la colonne tab_image.date_modif du WHERE dans la colonne possible_keys de l'EXPLAIN ! Ce qui laisse à penser que cette colonne tab_image.date_modif n'est pas indexée.

En local elle dure 2.4 sec

C'est encore beaucoup !
Le résultat devrait être immédiat, en tout cas dans une console MySQL ou dans phpMyAdmin !

On peut avoir la description des tables issue de SHOW CREATE TABLE nom_de_la_table ?

[LynxEyes]

Autant pour moi, j'avais 2 dates indexées mais pas celle là.
C'est rajouté :

Code :

1
2
3
4
5
6
7
+----+-------------+-------------------------+------+---------------------------+----------+---------+----------------------------------------+--------+-------------+
| id | select_type | TABLE                   | type | possible_keys             | KEY      | key_len | ref                                    | rows   | Extra       |
+----+-------------+-------------------------+------+---------------------------+----------+---------+----------------------------------------+--------+-------------+
|  1 | SIMPLE      | tab_prod_to_image       | ALL  | id_fiche,id,id_copy       | NULL     | NULL    | NULL                                   | 114538 |             |
|  1 | SIMPLE      | tab_image               | ref  | id,date_modif             | id       | 4       | db_test.tab_prod_to_image.id           |      1 |             |
|  1 | SIMPLE      | tab_prod                | ref  | id,cache_date             | id       | 4       | db_test.tab_prod_to_image.id_fiche     |      1 | USING WHERE |
+----+-------------+-------------------------+------+---------------------------+----------+---------+----------------------------------------+--------+-------------+

Au passage ça m'a permis de gagner 0.6 sec, pour cette requête je suis a 1.8 sec.

Pour info j'ai trouvé un autre endroit où je fais la même requête pour des tables équivalentes mais avec un peu plus de ligne (20 fois plus) ça met 4.75 sec au lieu de 6 sec (sûrement + de 10 sec chez le client)

[ericd69]

salut,

regarde les réglages mysql, essaye de jouer sur les différents caches dont celui pour les jointures...

tu y gagneras encore peut-être un peu... si tout est bien indexé les performances dépendent ensuite juste de la charge d'activité et de ce que doit bufferiser mysql...

à voir donc

[LynxEyes]

Ok, merci je vais y jeter un œil

[ericd69]

je te conseille de lire ça

à savoir que tu peux gagner aussi du temps en forçant l'utilisation des indexes, ça désactive l'optimiseur en utilisant using