Upload
community-motwin
View
105
Download
0
Embed Size (px)
Citation preview
Impact de la latence
+100ms de latence ⇒ -1% de revenu
+0,5s de temps de chargement additionnel ⇒ -20% de trafic
Temps de réaction du cerveau humain : 500msLatence applicative : peut atteindre plusieurs secondes!
5 ms de retard⇒ Perte de $4m/ms
Source : http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it
Les origines de la latence
Origines de la latence : ● État du réseau mobile● Réactivité du (des) backend(s) auxquels l’application
est connectée● Verbosité des APIs ● Nécessité de filtrer et d'agréger les données
Pas de cache Avantages
● Données toujours à jour quand on affiche l’écran
Inconvénients● Données non rafraîchies tant qu’on ne
change pas d’écran● Chargement des données à chaque fois
○ Forte dépendance réseau○ Charge sur le SI
Cache côté client + pollingAvantages
● Données toujours à jour quand on affiche l’écran
● Données rafraîchies régulièrement● Off-line possible
Inconvénients● Charge sur le SI (polling)● Utilisation de la bande passante, du CPU
et de la batterie sur le device● Comment déterminer une fréquence de
polling optimal?
Cache client + serveur + pollingAvantages
● Données à jour quand on affiche l’écran et rafraîchies régulièrement
● Off-line possible● Réduction de la charge sur le SI● Possibilité de téléchargement
conditionnel (ETag)
Inconvénients● La charge sur le SI peut devenir
importante si beaucoup de clients● Réduction de l’utilisation de la bande
passante et du CPU, mais toujours élevé● Nécessite de télécharger tout le
document même si une petite partie des données a changé
Middleware
Cache client + serveur + mises à jour incrémentales en mode push
Avantages● Off-line possible● Réduction de la charge sur le SI● Possibilité de détecter une modification
dans le cache● Mise à jour incrémentale permet d’
optimiser l’utilisation du réseau et du CPU
● Données toujours à jour
Inconvénients● ?
Middleware
∆
∆
Comment faire du Push ?
Nécessite une connexion bi-directionnelle permanente entre le serveur et le client
● Comet / Ajax / Long polling● Websocket● SSE
Comet/Ajax/Long polling
● Envoi d’une requête au serveur● Le serveur garde la requête ouverte un certain temps
○ Si donnée : envoi de la réponse○ Sinon : réponse pour terminer la requête
● Simule du Push● Supporté par tous les navigateurs● Pas performant en cas de mises à jour trop fréquentes
WebSockets
● Protocole basé sur TCP● Canal de communication bi-directionnel “full-duplex”
● Protocole spécifique pas supporté par tous les Firewall/Proxy
● Nécessite d’implémenter son propre protocole
SSE
● API Javascript (EventSource) permettant au serveur d’envoyer des évènements au client
● La norme prévoit le réveil des client par l’opérateur
● Envoi de données par le client pas couvert (latence plus importante)
● Basé sur HTTP, donc supporté par tous les Firewall/Proxy
● Pas supporté par tous les navigateurs
WebSocket SSE
Over a custom protocol Over simple HTTP
Full-Duplex, bi directional Server push only
Native support in most browsers Can be poly-filled to backport
Not straight forward protocol Simpler protocol
Pre-defined message handlers Arbitrary event
Application specific Built-in support for re-connection and event id
Require server/proxy config No changes required
ArrayBuffer and Blob No support for binary types
Le Push réduit l’overhead de 95%Surcharge de données inutiles échangées sur le réseau en Polling
1 polling/seconde
vs 1 message/seconde en Push
● Cas A : 1 000 clients ● Cas B : 10 000 clients● Cas C : 100 000 clients
Source : http://www.websocket.org/quantum.html