Le document discute des impacts de la latence sur l'application et les revenus, soulignant l'importance d'une optimisation efficace à travers des méthodes de mise à jour telles que le caching et le push. Plusieurs techniques pour le push sont analysées, incluant Comet, WebSockets et SSE, avec leurs avantages et inconvénients respectifs. Enfin, il propose une approche pour réduire les surcharges de réseau grâce à des messages optimisés en push.

1. CTO Crunch
Push : pourquoi et comment ?
Lorie Pisicchio

2. Impact de la latence
Temps de réaction du cerveau humain : 500ms
Latence applicative : peut atteindre plusieurs secondes!
+100ms de latence ⇒ -1% de revenu
+0,5s de temps de chargement additionnel ⇒ -20% de trafic
5 ms de retard⇒ Perte de $4m/ms
Source : http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it

3. 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

4. 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

5. Cache côté client + polling
Avantages
● 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?

6. Cache client + serveur + polling
Avantages
● 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

7. 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
Δ
Δ

8. Comment faire du Push ?
Nécessite une connexion bi-directionnelle permanente
entre le serveur et le client
● Comet / Ajax / Long polling
● Websocket
● SSE

9. 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

10. 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

11. Support WebSockets
Source : http://caniuse.com/#feat=websockets

12. 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

13. Support SSE
Source : http://caniuse.com/#search=Server

14. Notre prochain produit
Proxy aas
Pull
REST API
Push REST
API
Beta testeur ?

16. 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

17. 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

18. Motwin : MOS