Requêtes en arrière plan ?

Bonjour à tous,

Je suis actuellement à la recherche de cours ou de tutoriaux qui permet d'effectuer une action en arrière plan. Je ne sais malheureusement pas comment cela se nomme...

Le but serait d'accélérer l'affichage de pages web qui font appel à des requêtes lourdes. J'ai pour cela déjà créer des procédures stockées, mais ce que je souhaite c'est de pouvoir faire ça :

1 - L'utilisateur arrive sur le site internet
-> lancement de requête sql sur la base
2 - L'utilisateur change de page
-> la requête est toujours en cours d'exécution

Une autre possibilité serait éventuellement de charger régulièrement les requêtes dans un fichier cache sur le serveur, en exécutant un script cron toutes les minutes ?

Le but final est de récupérer la liste des membres de l'application, puis de faire des recherches grâce à la méthode ajax.

Je précise que la table membre est partitionnée 6 fois selon des tranches de lettres (a-e,f-h) ce qui représente à peu de chose prêt des partitions égales.

Merci d'avance pour les solutions apportées, je précise que je ne recherche que le moyen d'accéler le processus.

Koven

ya pas de réponse pure en html/php.
changement de page=nouveau script.

séquentiellement c'est toujours php qui se lance, qui fait ce qu'il a à faire, qui s'arrete en envoyant sa sortie en html vers le client.fin du script . Et php ne gère pas les threads...

Tant que tu concois ta page comme ça c'est pas possible de faire mieux.

pis un jour on a inventé le Dhtml et ajax et voilà...

tu a une page pour charger le site, et au milieu tu as un ptit applet js qui fait des requete http vers une page dissimulée qui execute tes requetes longues et compliquées sur mysql, pis retours à php qui transforme en json/xml/se qui faut puis renvoie au js qui a appelé.

Tout ça en moins de temps que les timeout acceptés par tes serveurs.

Tu peux utiliser la méthode un maximum en n'ayant qu'une seule page qui se met à jour avec de l'ajax et là comme tu peux executer plusieurs action js à la fois, tu peux executer plusieurs scripts php "à la fois".

Si c'est vraiment trop long, la méthode cron est la meilleure.

tu as combien d'utilisateur pour que la recherche d'une personne dans une table de personne prenne tant de temps????????????

C'est pour une future application, en fait je souhaiterai faire des recherches sur champs tels que le nom,prénom,CP,ville etc... avec la méthode ajax cela risque de prendre un temps fou si le nombre d'utilisateurs en devient conséquent.

Peut être que c'est une prise de tête pour rien du tout, mais je cherche à faire quelque chose optimisé et rapide dès le début, ça m'évitera de m'arracher les cheveux plus tard...

Mais ce que tu me dis me paraît un peu flou, il faut que je cherches du côté des applets js ??

salut,

en gros tu veux scanner tes tables en parallèle...

mais en fait, si tu partitiones sur un critère, pourquoi tu ne hashes pas ta recherche, avec ce critère, sur seulement la table concernée?

Hello

Les partitions sont déjà faites selon le pseudo de la personne. Ce que je souhaiterai c'est gagner en performance en chargeant toutes les infos d'un joueur (nom,prénom,ville,équipe...) et des équipes

Selon moi, le mieux serait de charger toutes les infos dans un tableau puis de faire des traitements ajax dessus sans refaire d'appel à la base de données.

Cependant, cela présente 2 inconvéniants :
- Devoir mettre à jour le tableau régulièrement
- Devoir stocker des données importantes en cache

N'étant vraiment pas expert mais toutefois intéressé par l'aspect performance, que me conseillez vous ?

(EDIT : ayant parfois du mal à exprimer mes données, c'est une sorte de moteur de recherche où je peux chercher des joueurs ou des équipes selon le nom, la ville...)

Soit faire des traitements ajax directement sur la/les tables de ma BDD sans préchargement, ce qui réduierait la vitesse de chargement

Soit pré-charger des données quand l'utilisateur clique sur 'recherche joueur => chargement table joueur, ou 'recherche équipe' => chargement table équipe)

Soit je me complique pour rien ? :mrgreen:

En espérant avoir quelques avis là dessus

merci d'avance
koven

cette partition n'est donc pas forcément judicieuse si tu ne cherches pas par nom de joueur...
et tu veux "charger ou cacher" ton tableau de données comment? faire un truc horrible en terme de mémoire que tu chargerais à la manière d'une session...?

php est pas pensé pour ça, c'est pas un langage compilé en JIT ou à l'avance et surtout pas multithread..

à partir du moment où tu n'as pas un système type archive, une partition horizontal (ici sur un critère lexicographique) est peu souvent une bonne idée...

:aie:

ensuite, l'utilisation d'un modèle de données bien fait, de poser de bons index et l'utilisation des procédures stockées pour encapsuler tes requêtes et limiter la bande passante seraient pour moi une meilleure voie...

:ccool:

Ok c'est noté, visiblement le mieux ce sont bel et bien les procédures stockées.

Merci pour vos réponses, bonne soirée

ça fait pas tout :mouarf:

comme je dis, un modèle et des requêtes bien construites aussi...

après, selon ton hébergement, les réglages du serveur mysql...

Pour le moment ce sera un hébergeur mutualisé, donc des paramètres mysql non modifiables sans doute.

J'aurai tout de même voulu savoir ce que tu entends par modèle ? c'est le modèle du MVC ou c'est complètement différent ?

Ce que je redoute c'est que le site soit lent sur cette partie recherche :(

en effet tu ne pourras pas optimiser tes caches...

non de ton modèle de données

si tu construis mal tes tables, tu plomberas clairement tes perfs...

tu dépend donc au départ de la modélisation de tes données...

exemple tes villes...

est ce qu'il vaux mieux avoir le nom ou un identifiant numérique dans ta table joueur?
ça dépend de la répétition potentielle...
si c'est une ville fictive (dans ton jeu) il vaut mieux certainement avoir un identifiant car elle se retrouvera sur de nombreux joueur...
si c'est une ville réelle idem en fait car si tu as de nombreux joueur dans une même ville ça deviendra plus performant de rechercher l'identifiant d'une ville que son nom... de plus tu compacte ta table donc tu rends plus efficace le cache...

de plus, une liste déroulante te permet d'afficher une valeur et de récupérer son identifiant... très pratique en ajax...

c'est à ce genre de chose que tu dois réfléchir...

En toute modestie, j'ai acquis des compétences de modélisation de données à l'IUT qui je pense sont correctes.

Effectivement je partage ton point de vue, mais cela me paraissait évident d'utiliser des identifiants.

Je cherche "simplement" à améliorer des performances de requêtes, j'ai l'impression que seules les procédures stockées et une bonne modélisation des données me permet d'améliorer ces performances.

Cela dit, lorsque l'on 'partitionne' une table, on réduit le nombre de champs d'une table, mais que se passe t'il côté serveur ?

Si par exemple j'ai une table ville, partitionnée en deux (p1 : A-M, et p2 :N-Z), lorsque l'utilisateur commence sa recherche par la touche 'S', est-ce que c'est le script php qui appel la table p2 ou c'est le serveur mysql qui se débrouille ? (j'entends par là les requêtes contenant LIKE)

Merci pour le temps accordé en tout cas, ce sujet m'intéresse réellement, mais n'hésites pas à me dire si je suis à côté de plaque :mrgreen:

le partitionnement tu n'y gagnes pas forcément...

d'où ce que je te dis... tu peux hashé ta recherche sur le pseudo... mais des recherches sur d'autres critères non car tu devras te taper toutes tes tables pour les autres critères...

de plus, tu augmentes le nombre de pointeurs de fichiers, le nombre de tables à bufferiser et donc si pour l'update la recherche par rapport à un pseudo c'est bien (à priori) c'est pas forcément vrai ensuite... surtout si tu montes en charge...

sans vouloir être méchant suffit de lire sur le forum pour voir des trucs rigolos pondus par des pros , ingénieurs ou autres :mouarf:

Ok ça sera tout pour moi :)

Je marque le sujet en résolu et je te remercie pour les réponses apportées;)