De meilleurs moyens que les méthodes de scrutin traditionnelles
Je suis actuellement dans un environnement AngularJS/Javascript.
Actuellement, l'application utilise la méthode d'interrogation (c'est-à-dire pour récupérer de nouvelles données du serveur en un nombre fixe de secondes).
Ceci est assez éprouvant et ne récupère pas immédiatement le dernier résultat. En supposant que le serveur utilise ASMX pour les fonctions de service Web et, si possible, sans refonte majeure, comment puis-je mieux améliorer l'efficacité de l'application?
Modifier 1:
En taxant, je veux dire que le serveur devrait extraire différentes tables SQL et les données et autres éléments associés, ce qui signifie un traitement de données complexe qui, s'il y a beaucoup d'utilisateurs simultanés, je crains qu'il puisse y avoir des problèmes avec les performances du serveur à l'avenir.
Les dernières données ne seront pas récupérées, car l'application utilise actuellement le type d'appels https de type demande-réponse.
Je peux améliorer davantage du côté des applications mobiles, mais je ne suis pas en mesure de modifier beaucoup du côté du serveur, à l'exception des fichiers de service Web du serveur.
Si par "traditionnel" vous voulez dire que chaque client martèle le serveur aussi souvent que possible, je peux vous aider au niveau architectural.
La conception appropriée dépend de l'emplacement de votre serveur dans cette grille:
Control \ Resources : Sufficient | Insufficient
Customizable : SC | IC
Untouchable : SU | IU
SC: Faites suivre au serveur le modèle d'observateur . Permettre aux clients de s'inscrire en tant qu'observateurs.
IC: autoriser uniquement un système proxy à s'inscrire auprès du serveur. Les clients s'enregistrent avec proxy.
SU: autoriser uniquement un système proxy à interroger le serveur. Les clients s'enregistrent avec proxy.
IU: autoriser uniquement un système proxy à interroger le serveur. Les clients s'enregistrent avec proxy.
Un proxy qui suit le modèle d'observateur peut résoudre à la fois les problèmes de personnalisation et de ressources. Cela fonctionne aussi bien sur Internet qu'entre les objets. Lorsque vous vous inscrivez, vous demandez à être appelé lorsque quelque chose se produit. Écoutez sur un port et vous êtes prêt à être appelé. ajax, REST, UDP, peu importe.
Le problème de l'interrogation est que l'observateur contrôle le moment où l'appel se produit, mais ne sait pas quand l'état change, il effectue donc de nombreux appels inutiles. Cela mange des ressources surtout quand il y a beaucoup d'observateurs. La clé pour faire face à l'interrogation est la suivante: obtenir dès que possible la direction des appels allant du point de changement d'état à l'observateur. Ensuite, les appels arrivent quand ils sont nécessaires. Pas quand ils ne le sont pas.
Si vous avez des appels d'interrogation dans ce sens:
- Serveur <=== Beaucoup d'observateurs
N'importe lequel d'entre eux serait un meilleur moyen de détecter les changements:
SC: Server ===> Beaucoup d'observateurs
IC: Server ===> Un proxy ===> Beaucoup d'observateurs
SU: Serveur <=== Un proxy ===> Beaucoup d'observateurs
UI: serveur <=== un proxy ===> de nombreux observateurs
Vous pouvez utiliser Server-Sent-Events comme alternative à l'interrogation.
Au lieu de demander à votre serveur de nouvelles données toutes les n secondes, ouvrez une connexion dédiée et demandez-lui d'envoyer vos nouvelles données dès qu'elles seront disponibles!
La connexion restera ouverte jusqu'à ce qu'elle soit explicitement fermée par le client ou le serveur (ou par leur interruption soudaine).
Vous pouvez configurer votre serveur pour diffuser des données à votre client à intervalles fixes, ou à des moments spécifiques sur votre serveur (permet de dire quand un objet change d'état ou quand un planificateur déclenche un travail ou quand).
Vous pouvez définir différents types d'événements et avoir différentes routines pour gérer différents types d'événements.
Côté serveur, vous pouvez conserver une file d'attente d'utilisateurs actuellement abonnés à votre type d'application/événement, lorsqu'un événement est créé, votre serveur le diffusera à tous les utilisateurs de la file d'attente. Des frameworks comme Jersey2 implémentent déjà cette approche en utilisant un objet Broadcaster .
Côté client, vous devrez écrire un service qui écoutera les événements envoyés par le serveur sur une URL spécifique .
Lorsque vous entrerez dans un état/itinéraire, vous devrez vous abonner à un type de serveur et vous désinscrire sur $destroy pour éviter une fuite.
Ce sont des websockets: ils sont une extension de HTTP, fonctionnent sur le même port.
Il permet une communication bidirectionnelle entre le client et le serveur et bien sûr il y a une intégration angularjs disponible pour cela.
Sinon, du côté du back office, si vous regardez Spring en Java, il y a d'autres façons de le faire:
- Interrogation longue
- STOMP
- ...
Cette lien covevr websocket et autres méthodes adaptées à ce dont vous avez besoin.
Notez que si vous n'avez pas Spring/Java, vous devez toujours le lire et rechercher une solution équivalente dans votre pile de technologies.
Vous devez mieux définir des choses comme "assez taxant" et découvrir pourquoi il ne récupère pas immédiatement le dernier résultat. Ce sont des questions qui se posent probablement, que vous interrogiez votre client ou non.
Cela dit, avec un frontal basé sur un navigateur, vous avez essentiellement deux options si vous souhaitez rester en javascript natif: interrogation (comme vous le faites, ou éventuellement longue interrogation) ou sockets Web. Je n'ai jamais vu de sockets Web effectuées avec ASMX auparavant (sans dire que cela ne peut pas être fait, juste que je n'ai pas d'expérience là-bas, donc je ne sais pas combien il serait difficile pour vous de réimplémenter). De plus, si vous rencontrez des problèmes de performances ou de précision, comme je l'ai dit, ceux-ci pourraient bien être toujours présents même avec l'utilisation de sockets Web.