PHP et multi-tâche ?

Version imprimable

02/12/2010, 17h29
steveWill

PHP et multi-tâche ?

Salut tout le monde
Je travaille avec php et Sybase, mais je constate qu'il n'ya pas de repertoire PHP/Sybase.
Du coup je poste ici.
Voici donc mon problème.

Je développe mon appli en php. et j'ai une BD sybase. Une fonctionnalité appelée 'Reload' consiste à l'appel d'une procédure stockée, qui elle procède à une série de Manipulations de la bd.(select/update...). La prod stock prend environ 5 min.
J'ai essayé de la simplifier, mais je n'ai pas de connaissances dans l'optimisation de requete sql, et une des vues sollicitées fait plus de 3millions de lignes! Ce temps d'attente de 5 min, et tres long, d'autant plus que cette fonctionnalité 'Reload' est assez sollicitée; d'où un gros problème de performance de mon appli, qui reste "bloquée" pendant 5min a chaque appel de 'Reload'.
Voici ma solution:
1. Créer une table qui contiendra le résultat de ma prod stock.
2. Créer un processus indépendant de mon appli qui mettrait à jour ma table de manière périodique. Le process vivra autant que l'appli vivra.

Mon problème est donc de savoir si le point 2 de ma solution est faisable ou non ? Comment le faire ? j'ai jetté un coup d'oeil sur les fonctions de flux sur php.net, mais ça ne me semble pas approprié.

Si quelqu'un peut m'aider, ce serait génial.
Merci
02/12/2010, 17h56
gwinyam

Quand t'entend multi-tâches, je suppose que tu penses thread. Ce n'est pas la bonne approche en ce qui concerne un développement web et encore plus PHP où tu ne peux pas faire de threads, enfin pas explicitement.

Cependant, tout n'est pas perdu, puisque tu peux très bien faire un appel Ajax depuis ton appli. Celle-ci continuera d'être dispo pendant que le traitement se fait.
02/12/2010, 22h51
ThomasR

Je pense que tu souhaites exécuter un script en background, via AJAX. De cette manière le navigateur n'est pas ralenti.
03/12/2010, 06h31
hornetbzz

Bonjour,

Qq idées plus basées sur le bon sens paysan (en ts cas j'essaye) que sur mon expérience en la matière :

- le stockage du resultat de la requete périodique me parait une bonne idée,

- ça vaudrait probablement le coup de se fendre d'un peu d'optimisation de la db quand même, et des requetes (cf par exemple les requetes préparées, rapproches toi des spécialistes dans le forum adéquat)

- la génération périodique de la table qui contiendra le résultat de ma "prod stock" peut s'effectuer de moultes façons. A priori, rien ne t'empêcherait de ne conserver que ta partie de code qui génére le résultat, et appeler ce code périodiquement via un cronjob par exemple. Indépendemment du client.
Tu peux aussi couper à nouveau le probleme en deux : coder un "gros" cronjob de nuit, et un plus petit, moins consommateur de ressource, à intervalles réguliers dans la journée.

- pour la partie client, ça devrait déjà bien alléger les choses. Ceci dit, le client peut effectivement lancer une requete auprès du serveur sans être pour autant constitué prisonnier. Effectivement, la technique s'appelle Ajax: le client envoie une requete auprès du serveur, qui lui répond gentillement. Mais cela permettra uniquement (au client) d'éviter le rechargement de la page en cours, et de continuer à naviguer sur cette même page, tout en ayant lancé la requete auprès du serveur. Mais il faudra quand même que l'objet ajax puisse être récupéré sur la même page que la page appelante.

Tel que tu décrit ton probleme, la solution me parait plus être dans l'optimisation de ta base et des requetes, et effectivement dans la préparation d'une table "pseudo statique" de résultats que dans la problématique "Ajax".

Voilà pour la prose. Maintenant, bon courage et yaka yfôkon.. :-)
03/12/2010, 09h00
gwinyam

Citation:

Envoyé par hornetbzz

- pour la partie client, ça devrait déjà bien alléger les choses. Ceci dit, le client peut effectivement lancer une requete auprès du serveur sans être pour autant constitué prisonnier. Effectivement, la technique s'appelle Ajax: le client envoie une requete auprès du serveur, qui lui répond gentillement. Mais cela permettra uniquement (au client) d'éviter le rechargement de la page en cours, et de continuer à naviguer sur cette même page, tout en ayant lancé la requete auprès du serveur. Mais il faudra quand même que l'objet ajax puisse être récupéré sur la même page que la page appelante.

Ceci dit, si c'est dans une vraie application à interface riche (RIA), ça ne pose aucun souci ce genre de choses, on peut continuer à naviguer entre plein de choses tout en étant en attente d'une réponse Ajax.