Principes d'une communication optimisée PHP Javascript

Maintenant que l'on sait faire communiquer le javascript avec une API en PHP, nous allons voir comment améliorer notre script pour éviter de surcharger inutilement l'utilisation de ressources que ce soit en terme de serveur, de bande passante et de ressource processeur coté navigateur.

Fonctionnement actuel

Pour le moment, la méthode utilisée fonctionne sur une boucle continue qui va réinterroger le serveur à intervalle régulier. Pour que les changements soient instantanés à l’écran, la fréquence de rafraîchissement doit se trouver autour des 30 millisecondes.

Ensuite, de son côté, le serveur renvoie systématiquement les données demandées même si elles sont identiques aux données précédentes.

On voit bien que ce fonctionnement n'est pas optimal.

Fonctionnement souhaité

Dans l'idéal on souhaite que le serveur ne communique que les changements et cela dès qu'ils ont lieu. On évite ainsi les requêtes à répétitions et l'envoi de données inutiles.

Quand j'ai commencé mes recherches, j'ai vu qu'il s'agissait du principe des sockets. On ouvre un socket sur lequel on peut écouter les réponses du serveur. Mais l'utilisation des sockets demande d'utiliser des librairies, ce qui ne me convenait pas...

J'ai donc continué à réfléchir et j'ai trouvé une solution !

Créer un système "d'API listener" en javascript

Cette solution revient à coupler une requête XMLHTTP qui agit comme un listener avec un script d'API qui ne répond qu'en cas de changement des données.

A la réception des données, le script javascript renvoie une nouvelle requête, ce qui démarre une "nouvelle écoute", etc... Ce qui donne l'illusion d'avoir une sorte de listener sur l’événement "changement des données côté serveur".

En complément, il est possible d'aller plus loin en filtrant les données transmises par le serveur pour limiter le transfert aux seules données qui changent.

Les choses à faire :

• Pour créer une API qui réponde qu'en cas de changement, il faut faire entrer le script dans une boucle. Mais pour limiter les ressources serveur, il faut lui accorder des pauses dans cette boucle. Pour cela on va utiliser la fonction usleep, qui permet de faire des pauses en microsecondes.
• La requête javascript ne se déclenchera pas à intervalles réguliers mais dès qu'une réponse aura été obtenue du serveur. De manière à ce qu'il y ai toujours une requête en cours mais tout en limitant au maximum leur nombre.
• En pratique les serveur n'autorisent pas un script PHP à tourner en continue et une erreur est renvoyée si le script tourne trop longtemps sans se terminer. Pour cela, on définira qu'après 60 secondes, le serveur répondra même s'il n'y a pas de changements, ce qui déclenchera une nouvelle requête javascript et évitera les réponses d'erreur du serveur.
• Enfin, il faut filtrer les données en les comparant aux dernières données transmises pour conserver les données qui changent, ne pas oublier de transmettre les données qui disparaissent.
• Limiter les requêtes en supprimant les requêtes dédiées à la récupération des "vues" HTML et les écrire en javascript.

Nous allons voir dans l'article suivant comment passer outre un problème que j'ai rencontrer pour réaliser un script de ce type. Ce problème vient de la gestion des SESSIONS en PHP qui empêche les accès simultanés pour une même SESSION... Nous allons résoudre ça à l'aide de la fonction session_write_close ();