Discussion :

[Mister Paul]

Bonjour,

j'ai un site hébergé en mutualisé chez OVH. J'ai récupéré un code qui fait une requête Ajax toutes les 5 secondes depuis ce site vers l'url d'une WebRadio.
Cette radio met à disposition dans un fichier json ce qu'elle diffuse en direct. Si le contenu est modifié on récupère le contenu json pour le traiter.
Etc. toutes les 5 secondes

- Euh ce n'est pas trop lourd comme manière de procéder ?

A votre avis,
- OVH acceptera celle fréquence sur un mutualisé ?
- La radio acceptera d'être interrogé à cette fréquence ?


Merci pour vos infos !
PAul

[Watilin]

J'ai récupéré un code qui fait une requête Ajax toutes les 5 secondes depuis ce site vers l'url d'une WebRadio.

[…]

A votre avis,
- OVH acceptera celle fréquence sur un mutualisé ?

OVH ne verra rien : les requêtes ajax sont émises par les navigateurs de tes utilisatrices et utilisateurs. Du moins si tu parles bien d’ajax, car ajax c’est JavaScript, et il n’y a pas de JavaScript sur les serveurs d’OVH (à ma connaissance).

- La radio acceptera d'être interrogé à cette fréquence ?

C’est un autre problème. Si le code que tu as trouvé fonctionne, cela signifie qu’il utilise la mécanique CORS, et ainsi l’adresse de ton site apparaît nécessairement dans l’en-tête Origin des requêtes Ajax.

Si ton site a une bonne fréquentation, et si la web radio implémente une protection anti-DDoS (par exemple via CloudFlare), il y a une possibilité que ton domaine finisse en liste noire. C’est juste une hypothèse.

As-tu essayé de déterminer approximativement à quelle fréquence le JSON est mis à jour ? Ça pourrait être bien plus de 5 secondes.

[Mister Paul]

As-tu essayé de déterminer approximativement à quelle fréquence le JSON est mis à jour ? Ça pourrait être bien plus de 5 secondes.

C'est vraiment toutes les 5 secondes que l'Ajax vient voir si le json a été modifié par la radio.
C'est systématique. Un peu force brute, non?...

J'aurais préféré que l'Ajax vienne à l'heure de fin du morceau (on a cette info dans le json) voir si le json a été modifié (= s'il indique le nouveau morceau) et que s'il ne l'a pas été (des fois il y a ± 30 secondes de décalage dans la mise à jour du json) il repasse toutes les 5 secondes checker la mise à jour. Et seulement dans ce cas-là...
Mais ça voudrait dire récupérer des variables ("end_at"="2018-07-22T07:14:53+0000") et comparer avec l'heure actuelle.

Il faudrait que je questionne directement la radio.
Ceci dit le json est fait pour communiquer l'info de ce qu'il diffusent. Donc il est là pour être interrogé.
S'ils acceptent les 5 secondes ce n'est peut-être pas la peine de développer plus fin... (?)

[Watilin]

C'est vraiment toutes les 5 secondes que l'Ajax vient voir si le json a été modifié par la radio.
C'est systématique. Un peu force brute, non?...

Oui et non, ça dépend du contexte. Entre autres, la latence du réseau, mais ça c’est difficile à prévoir, et la capacité du serveur qui sert le fichier JSON. Si tu constates qu’il met souvent plus d’une seconde à répondre, il vaut mieux diminuer la fréquence des requêtes.

À toi de trouver un équilibre entre le confort d’utilisation – quand les choses ne se passent pas bien, quelle durée de silence est acceptable — et la « légèreté » des requêtes.

J'aurais préféré que l'Ajax vienne à l'heure de fin du morceau […]
Mais ça voudrait dire récupérer des variables ("end_at"="2018-07-22T07:14:53+0000") et comparer avec l'heure actuelle.

C’est tout à fait faisable

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
let end_at = json. ... .end_at;
let endDate = new Date(end_at);
let timeDiff = endDate - Date.now();

Si tu as du mal à extraire l’information end_at, montre-moi la structure du JSON et je te donnerai un coup de main.

timeDiff te donne la différence en millisecondes entre l’heure de fin de morceau et l’heure actuelle. Si c’est positif, la fin du morceau est dans le futur ; si c’est négatif, elle a déjà eu lieu.
Tu pourrais utiliser setTimeout avec par exemple comme délai timeDiff - 5000 pour lancer une requête 5 secondes (5 000 millisecondes) avant la fin du morceau.

Il faudrait que je questionne directement la radio.

C’est une bonne idée, et ça pourrait te donner d’autres informations utiles

S'ils acceptent les 5 secondes ce n'est peut-être pas la peine de développer plus fin... (?)

C’est une question de parcimonie. Des requêtes plus fréquentes que nécessaire, c’est une consommation d’énergie superflue. N’oublie pas que chaque requête fait fonctionner tout un tas de machine dans le grand Internet, des multiplexeurs, des routeurs de bordure, des répétiteurs, éventuellement des proxys, et aussi les boîtes noires de notre copain Bernard Cazeneuve. Bref, l’optimisation, c’est aussi un peu de l’écologie

[Mister Paul]

Si tu as du mal à extraire l’information end_at, montre-moi la structure du JSON et je te donnerai un coup de main.

Merci pour ta proposition.