CTO Crunch
Push : pourquoi et comment ?
Lorie Pisicchio

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

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 + 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?

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

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

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

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

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

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

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

Motwin : MOS