Discussion :

[Elianora la blanche]

Bonjour à tous !

sur un projet, je lance des recherches sql très lentes (plus de 200 millions de lignes dans la table concernée et on peut rechercher sur des champs non indexés, bref, c'est lent mais c'est "normal").
Souci : notre reverse proxy kille la connexion au bout de 5 minutes (normal) mais certaines grosses recherches durent plus de 5 minutes...

Pas grave, me suis-je dit, je vais réduire (une fois n'est pas coutume) max_execution_time à 4 min 30 s pour avoir de la marge (qui, allez savoir pourquoi, était largement au-dessus des 5 minutes !!! ) c'est moche mais moins que la page d'erreur du reverse proxy ^^
sauf que c'est attendre la réponse sql qui prend du temps, pas le traitement php (qui, lui, est autour d'1s entre l'appel sql et la réponse une fois les données récupérées donc rien d'anormal) et du coup, max_execution_time est tout bonnement ignoré (j'ai appris un truc)

y a-t-il une autre manière d'arrêter mon script php avant le délai de 5 minutes ?
si possible de manière pas trop dégueu ^^

merci d'avance,

PS : je sais, il faut surtout réduire le temps de traitement sql, on y travaille, mais rien de miraculeux jusqu'ici
je pense que mariadb n'est pas le bon système pour cette volumétrie mais c'est un autre sujet

[psychadelic]

Pas la bonne méthode.

l'idéal : découper la requête pour avoir une réponse par tranches
( PS: coté SQL utiliser une requêteprocédure stockée)

coté Client appel PHP,
1 faire la demande
2 relancer toute les minutes le serveur PHP pour savoir si la réponse est prête, et afficher une attente
3 quand pret récupérer l'ensemblle

coté client PHP appel SQL
même stratégie, en utilisant une table SQL temporaire qui donnera la réponse au client final

On peut aussi avoir différentes tables temporairee corélation d'une fourchette d'argument, et les gérer comme un proxi "maison"

[Elianora la blanche]

je sais bien que c'est pas la bonne méthode, mais comme je n'ai la main que sur le php, j'essaye de trouver une astuce (c'est très moche, je sais) en attendant un miracle des optims côté sql ^^

alors, c'est déjà découpé d'une certaine manière (1000 par 1000 pour la pagination, pas de count total évidemment ^^)
mais, par ex, une requête qui ne retourne que 50 lignes prend quand même plus d'1 min
je ne vois donc pas trop que découper de plus (à part revoir la structure de la table elle même mais c'est de la conception, c'est pas à ma main et c'est pas vraiment le sujet non plus)

la partie côté client étant déjà en ajax, temporiser devrait pouvoir se faire sans trop de souci (à tester, voir si ça suffit)

par contre, la table temporaire, je ne vois pas trop... elle contiendrait quoi ? une "copie" de la table ? si oui, ça tiendra pas en ram ^^ si non, faudra bien le temps d'y mettre "juste" ce dont on a besoin, ça ne fait que déporter le problème, non ?

requête stockée, c'est quoi ? je connais les procédures stockées... Et si les utilisateurs lançaient tjs les mêmes recherches, ce serait trop simple
et vu qu'il y aura (en prod) énormément d'insert (environ 8 millions / jour), le cache requête a carrément été désactivé (c'est logique en même temps, il ne vivrait pas longtemps de toute façon)

l'utilisation métier est assez "temps réel"

[psychadelic]

requête stockée, c'est quoi ? je connais les procédures stockées... Et si les utilisateurs lançaient tjs les mêmes recherches, ce serait trop simple

oui, procédure stockée, mais on peut aussi utiliser des paramètres en entrée sur une procédure stockée.

table temporaire => créer une table recevant les résultats de la requête puis ensuite l'utiliser pour l'afficher en tranche, classiquement à la demande
http://www.mysqltutorial.org/mysql-temporary-table/
https://dev.mysql.com/doc/refman/5.7...ary-table.html

Si tu n'a acces qu'au PHP, rien n'interdit de créer une procédure stockée par ce biais ou une table temporaire,, ou encore une vue ce qui peut aussi être une meilleure solution

https://dev.mysql.com/doc/refman/8.0...eate-view.html

[Elianora la blanche]

OK, je vois
il faut que je regarde en terme d'occupation mémoire car on est déjà limite avec les données "brutes"

j'ai accès au serveur de bdd, c'est juste que je ne peux prendre aucune décision qui modifie quoi que ce soit car ça ne dépend pas de moi donc je peux créer des procédures stockées (mais je maitrise mal et ce n'est pas moi qui ferai la maintenance, alors il vaut mieux rester sur des trucs "simples" ^^)

EDIT : j'ai fait quelques tests mais ça ne va pas : mon premier appel (= page 1 des résultats) crée une table temporaire et mes appels suivants (= pages >= 2) utilisent la table temporaire
sauf que... c'est pas le même "client" (au sens sql), donc la table temporaire créée par mon premier appel n'existe QUE pour cet appel
donc ça ne sert strictement à rien (à part rajouter du traitement) ^^
et en plus, j'ai pas essayé avec les données réelles donc je ne suis tjs pas certaine que ça tienne le choc

j'ai pensé faire une vue plutôt mais chaque utilisateur différent va régénérer la vue à chaque nouvelle recherche donc ça ne va pas aller non plus

[psychadelic]

À part l'idée de créer une "vraie" table avec les resultats que tu efface des qu'il y a une mise à jour des données originelles, ou disons toutes les 2 heures, ...

Il y a aussi l'idée d'utiliser une seconde base de données en parallèle qui récupère périodiquement les synthèses utiles sur la première base.

sinon, je vois pas trop, ça ressemble à une impasse...

[ABCIWEB]

y a-t-il une autre manière d'arrêter mon script php avant le délai de 5 minutes ?
si possible de manière pas trop dégueu ^^

Peut-être déclencher un settimeout en javascript lors de l'exécution du script, qui lancera une requête ajax à 4min55 pour arrêter la requête sql en cours. Il y a un sujet qui pourrait peut-être t'aider ici.

Sinon il existe aussi l'équivalent d'un settimeout en php avec la classe EvTimer mais je ne pense pas qu'elle fasse partie du package standard de php, il faudrait donc sans doute l'installer.

[Elianora la blanche]

À part l'idée de créer une "vraie" table avec les resultats que tu efface des qu'il y a une mise à jour des données originelles, ou disons toutes les 2 heures, ...

Il y a aussi l'idée d'utiliser une seconde base de données en parallèle qui récupère périodiquement les synthèses utiles sur la première base.

sinon, je vois pas trop, ça ressemble à une impasse...

le problème est le même dans tous ces cas : on n'a pas des données fraiches (je ne connais pas la fréquence d'insert mais 8 millions par jour, ça fait en moyenne pas loin de 100 / s...) donc pas temps réel (donc pas acceptable d'un point de vue métier)

je pense aussi être dans une impasse
je vais regarder pour killer en js si nécessaire

d'autres personnes s'occupent d'essayer d'optimiser côté sql, il y a peut-être encore un espoir ^^

merci !

[Elianora la blanche]

bon, ils ont réussi à trouver une solution efficace côté sql et les temps de traitement sont désormais acceptables

je garde l'idée quand même, pour d'autres projets, au cas où ^^