CTO CrunchPush : pourquoi et comment ?

Lorie Pisicchio

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

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