Bonjour,
je veux afficher dans une page web des données issues d'une base de données ; ces dernières sont continuellement mises à jour par une autre application. Ma page web doit afficher les données en temps réel (à quelques secondes près).
Pour cela, j'ai fait d'un côté un service web qui fournit un flux XML contenant les données à afficher, et de l'autre une page web en ajax, qui fait une requête GET asynchrone sur mon service toutes les 5 secondes. Ça fonctionne.
Seulement, cela consomme trop de bande passante pour moi (connexion GPRS facturée au ko, et page web tournant 24/24h).
Du coup, j'ai testé ceci : côté serveur, le webservice tourne en boucle jusqu'à ce qu'une modification survienne dans la base de données. A ce moment là seulement le flux est envoyé.
Comme ça pendant ce temps, côté client, la requête Ajax reste en mode readyState = 3, donc pas de consommation réseau.
Sauf qu'au bout de 30 secondes, le webservice s'interrompt, normal
Je suis administrateur du serveur, donc je peux faire sauter cette restriction, mais je voudrais savoir si sur le principe, mon architecture est bonne, et si ce n'est pas le cas, comment faire plus propre.
Merci d'avance !
Forum Programmation.php Faire tourner un script PHP en boucle indéfiniment : bien ou pas bien ?
17
déc.
2008
# lapin compris
Posté par NeoX . Évalué à 2.
pour savoir si un truc à changer puis avertir l'usager (le navigateur du client) que ca a changé pour qu'il vienne chercher la mise à jour.
pourquoi ne pas faire un refresh volontaire de la part du client.
il a les données au moment ou il se connecte "au temps T"
s'il veut (et qu'il est pres à mettre de la 3G/GPRS dedans) les données à T+60sec, ben il rafraichit 60s plus tard...
sinon dans les 2 cas, tu vas forcer le "client" à rafraichir les données ....
[^] # Re: lapin compris
Posté par santos . Évalué à 3.
Or, bien que je souhaite afficher les données avec un délai maximum de 5 secondes environ, en pratique les données changent occasionnellement, et surtout aléatoirement (en moyenne toutes les heures). Du coup, avec ma méthode, outre lors de l'initialisation de la requête, aucune donnée n'est transférée ni dans un sens ni dans l'autre tant que les données ne changent pas dans la base.
En gros, c'est comme attendre que le facteur sonne à ma porte, plutôt que de guetter à intervalles réguliers, voir s'il n'est pas en train d'arriver.
A moins que je me trompe, tant que mon script côté serveur n'est pas entièrement exécuté, la requête du client est en statut readyState = 3. Durant tout ce temps, qui dans mon cas, peut durer plusieurs heures (enfin si j'enlève la restriction de 30 secondes de PHP), aucune donnée n'est transférée, ni dans un sens ni dans l'autre.
# Not modified
Posté par wismerhill . Évalué à 9.
Cela devrait te limiter beaucoup la quantité de données envoyées.
[^] # Re: Not modified
Posté par santos . Évalué à 2.
Avec cette solution, le client continue quand-même à initier une requête toutes les 5 secondes, et reçoit à chaque fois une réponse (même si effectivement elle n'est pas grosse, avec ce que tu proposes).
Or, en pratique, les données ne changent en moyenne qu'une fois toutes les heures (mais ce délai est complètement aléatoire). Donc ça fait 719 requêtes inutiles par heures, ça fait plus de 500 000 requêtes inutiles par mois. Sur une connexion GPRS facturée au ko, c'est sensible.
[^] # Re: Not modified
Posté par wismerhill . Évalué à 2.
Le délais est aléatoire, mais ton serveur peut-il l'estimer (même grossièrement)?
Si oui tu peux ajouter le header Expires (http://www.freesoft.org/CIE/RFC/2068/182.htm ) pour indiquer au client à partir de quand ça vaut la peine de refaire une requète.
[^] # Re: Not modified
Posté par santos . Évalué à 2.
[^] # Re: Not modified
Posté par santos . Évalué à 2.
[^] # Re: Not modified
Posté par santos . Évalué à 2.
En termes de consommation en bande passante, j'ai regardé avec firebug :
- le chargement de mon flux XML lorsqu'il contient des données mises à jour prend environ 900 octets ;
- une réponse "304 Not modified" semble trop petite pour être évaluée par firebug (qui met un ? à la place de la taille).
A mon avis c'est un bon compromis.
[^] # Re: Not modified
Posté par wismerhill . Évalué à 2.
- une réponse "304 Not modified" semble trop petite pour être évaluée par firebug (qui met un ? à la place de la taille).
C'est parce qu'il n'y a aucun contenu avec la réponse 304, et dans tes 900 octets les headers ne sont probablement pas comptés.
Côté serveur avec un apache tu peux voir la taille réellement reçue/envoyée avec le mod_logio
http://httpd.apache.org/docs/2.2/mod/mod_logio.html
# PHP Socket Daemon
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 2.
http://code.google.com/p/phpsocketdaemon/
http://www.chabotc.com/phpsocketdaemon/
# en prenant les choses par l'autre bout
Posté par bertrand . Évalué à 2.
Le prog qui les met à jour ne peut pas envoyer un flux vers le poste client ?
Dans cette optique, tu as un service qui tourne sur le poste client, et qui attend de recevoir un message. A réception, il affiche les données.
Comme ça tu n'a des infos qui transitent que s'il y a mise à jour.
[^] # Re: en prenant les choses par l'autre bout
Posté par santos . Évalué à 2.
Or ça non ce n'est pas possible (plusieurs centaines de clients, connexions GPRS qui ne permettent pas de se connecter à distance sur la machine, etc...)
Mais en théorie oui c'est sûr que ce serait l'idéal.
[^] # Re: en prenant les choses par l'autre bout
Posté par MsieurHappy . Évalué à 3.
Peut-être pas le plus adatpé, mais le premier à me venir à l'esprit c'est XMPP, via le mécanisme PubSub.
[^] # Re: en prenant les choses par l'autre bout
Posté par santos . Évalué à 2.
[^] # Re: en prenant les choses par l'autre bout
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.