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...
Les origines de la latence 
Origines de la latence : 
● État du réseau mobile 
● Réactivité du (des) backend(s) auxquels l...
Pas de cache 
Avantages 
● Données toujours à jour quand on 
affiche l’écran 
Inconvénients 
● Données non rafraîchies tan...
Cache côté client + polling 
Avantages 
● Données toujours à jour quand on 
affiche l’écran 
● Données rafraîchies réguliè...
Cache client + serveur + polling 
Avantages 
● Données à jour quand on affiche l’écran 
et rafraîchies régulièrement 
● Of...
Cache client + serveur + mises à jour 
incrémentales en mode push 
Avantages 
● Off-line possible 
● Réduction de la charg...
Comment faire du Push ? 
Nécessite une connexion bi-directionnelle permanente 
entre le serveur et le client 
● Comet / Aj...
Comet/Ajax/Long polling 
● Envoi d’une requête au serveur 
● Le serveur garde la requête ouverte un certain temps 
○ Si do...
WebSockets 
● Protocole basé sur TCP 
● Canal de communication bi-directionnel “full-duplex” 
● Protocole spécifique pas s...
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éve...
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 mo...
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 ...
Motwin : MOS
Motwin -  cto crunch - 141205 - Optimiser la latence applicative mobile
Prochain SlideShare
Chargement dans…5
×

Motwin - cto crunch - 141205 - Optimiser la latence applicative mobile

486 vues

Publié le

Comment optimiser la latence mobile grâce aux protocoles/technologies de push et à la gestion du cash ?

Description des différentes solutions

Présentation de Lorie Pisicchio lors du CTO Meetup du 03/12/14 organisé par France Digital

Publié dans : Mobile
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
486
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
3
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Motwin - cto crunch - 141205 - Optimiser la latence applicative mobile

  1. 1. CTO Crunch Push : pourquoi et comment ? Lorie Pisicchio
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 11. Support WebSockets Source : http://caniuse.com/#feat=websockets
  12. 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. 13. Support SSE Source : http://caniuse.com/#search=Server
  14. 14. Notre prochain produit Proxy aas Pull REST API Push REST API Beta testeur ?
  15. 15. 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
  16. 16. 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
  17. 17. Motwin : MOS

×