Retour aux actualités
Article suivant Article précédent

Revue 174 - La performance applicative mobile un problème complexe

Articles Revue TELECOM

-

15/10/2014


La performance 

applicative mobile


 

un problème complexe

 

Par Eric Horesnyi (1996) dans la revue TELECOM n° 174
 

Pourquoi la rapidité est-elle si importante pour nous les humains ?

Lorsqu’elle s’adresse à des machines, la technologie peut imposer encore ses règles internes qui seront respectées. Mais lorsque la technologie sert des humains, nous devons respecter les règles héritées de notre fonctionnement interne. La physiologie, qui étudie le fonctionnement de notre corps à dessein médical, nous apporte des réponses.

Lorsqu’un humain interagit avec son smartphone (ou toute application à travers un objet connecté), il s’investit d’autant plus émotionnellement dans sa relation avec l’application que son comportement lui semble humain. Le temps de réaction humain se situe entre 150 et 470 ms suivant le sens sollicité et le traitement nécessaire. Donc toute application réagissant avec plus d’une demi-seconde semblera artificielle.

Google confirme ce chiffre dans ses recommandations aux développeurs, suite aux études continues du comportement des utilisateurs : 500ms est le délai à atteindre pour tout développeur d’application agréable.
 

Le problème du mobile avec la performance applicative

Pour atteindre ce benchmark de 500ms, un développeur sur mobile se retrouve dans une situation bien plus délicate qu’un développeur sur desktop : le temps de latence du sous-jacent réseau actuellement de 1 à 2 ms en réseau fixe, atteint 200ms sur réseau mobile ! Soit un budget temps multiplié par 100 pour la couche réseau.

 

Temps de Réaction - Source : Public Library of Science



Ceci ramène un développeur desktop aux années 1990 du web, ou à consulter (sans cache, donc un site très peu utilisé !) un site Chinois ou Indien. Le pire, c’est que ses utilisateurs ne sont plus les êtres patients que nous étions alors, les utilisateurs s’attendent à la même performance que sur le web.

Si nous voulons évaluer l’impact de latence réseau sur la performance applicative, nous pouvons le résumer dans cette équation :


Effect of latency on maximum TCP throughput
Source : http://www.digitalsociety.org/2010/08/conflating-broadband-speed-with-internet-speed-is-misleading/


Latence Applicative pour un contenu affiché =
Nombre d’Applications Sollicitées (richness) x
(Nombre d’Aller-Retour par Application (chattiness) x
Nombre de paquets pour transmettre le volume de données (data volume) x
Latence Aller-Retour (round trip delay)
+Temps de Traitement Applicatif (CPU processing)).

Au delà de l’impact catastrophique d’un facteur réseau (round trip delay) x100 dans cette équation sur la latence applicative, les autres facteurs ne semblent pas aider. En effet, côté richness : avec l’adoption rapide du cloud pour la construction d’applicatifs SAAS, les données proviennent de plus en plus d’une ou plusieurs applications cloud en plus du système propriétaire, sans oublier les réseaux sociaux. Le data volume augmente également avec l’utilisation de plus en plus massive de vidéo, ou de contenus sophistiqués issus du big data, suivant la loi de Moore (doublement tous les 18 mois). Seule la chattiness peut être corrigée par une bonne discipline des développeurs, et le CPU processing suit la loi de Moore (divisé par 2 tous les 18 mois).

La 4G représente un espoir pour le round trip delay (round trip à 100ms), de même que les technologies qui lui succéderont. Malheureusement, l’augmentation de débit offert ne suit pas l’augmentation du volume de sources (richness), et encore moins le nombre de paquets transmis (data volume) qui suivent la Loi de Moore.
 

Existent-il des solutions pour ceux qui ne peuvent pas attendre ?

Les solutions utilisées pour le web « desktop » (CDN, Matériels, mémoire cache, …) sont toujours disponibles mais ne suffisent plus face aux particularités du web mobile. Deux types de solutions s’imposent pour réduire, d’un côté, le facteur « richness » avec l’orchestration de données et, de l’autre côté, le facteur « Latence Aller-Retour » avec la confirmation des protocoles de communication bidirectionnelle.

A ce jour, une solution a émergé pour aider les développeurs à affronter ce défi : l’orchestration de données. Un agent logiciel représentant l’objet connecté s’insère dans le cloud et en face de l’équipement sans fil. L’agent représente l’objet connecté vis-à-vis desmultiples sources cloud avant de n’envoyer à l’objet connecté que les informations essentielles pour sa présentation.


Par ailleurs, cette même architecture initialement prévue pour le sans fil distant traite les problèmes de wifi saturé, ou de bande passante Internet artificiellement faible, par exemple pour les éditeurs SAAS à travers le Great Firewall of China.

Le facteur « latence aller-retour » peut être réduit de moitié en supprimant l’aller (ou le retour !) avec les protocoles de communication bidirectionnelle



Orchestration de Données pour humains connectés -Source : Motwin


En reprenant nos cours Réseaux, nous pouvons constater que le protocole HTTP est en mode « Resquest-Answer ». Le mobile, pour avoir une information, doit poser une question au serveur. Ainsi la réactivité supporte le poids du temps de communication aller et retour. Les protocoles de communications bidirectionnelles en revanche permettent de créer un canal (un socket) de communication constant entre le mobile et le serveur. Si le serveur se rend compte qu’une donnée a changé de son côté, il peut pousser de lui-même des informations vers le mobile, sans attendre de question. Le plus connu de ces protocoles est Websocket, normalisé par l’IETF dans la RFC 6455 en 2011. Bien qu’il reste des éléments à spécifier, le protocole connait déjà un grand succès pour les applications les plus sensibles au temps (trading, betting, BtE, jeux à réalité augmentée, …). L’intégration de plus en plus d’interactivité (chat, réseaux sociaux, news, …) dans toutes les applications et les pages web forcera les développeurs à mieux maîtriser ce nouveau protocole.

L’orchestration et les protocoles bidirectionnels vont bientôt devenir une évidence pour tous car, non seulement ils permettent de réduire la latence applicative, mais ils luttent également contre le second plus gros ennemis de l’expérience web mobile : le manque debatterie ! En réduisant le nombre de paquet à envoyer et à recevoir, on réduit le besoin en énergie d’une application et on augmente son usage par ses clients ou ses employés. Et qui n’est pas confronté quotidiennement à cette terrible dernière petite barre rouge ?
 


Ressources

Public Library of Science : http://www.ncbi.nlm.nih.gov/pmc/articles/PMC548951/figure/pbio-0030051-g002/

ENS Lyon : http://acces.ens-lyon.fr/acces/ressources/neurosciences/temps-de-reaction-investigation-variabilite-et-traitements-statistiques-des-donnees/comprendre-1/le-temps-de-reaction-quest-ce-que-cest/
 



L’auteur
 


Eric 
Horesnyi (1996),
 CEO, MotwinEric dirige Motwin, éditeur français d’APIs temps réel sécurisées pour une expérience utilisateur haut de gamme et multi-channel : mobiles, tablettes, web et objets connectés. Au préalable, Eric a développé la practice Finance de BT en France, lesarchitectures de trading haute fréquence de Radianz aux USA après avoir travaillé comme consultant en performance applicative chez Equant. Eric est Ingénieur Télécom ParisTech 1996 et MBA NYU Stern.




 

371 vues Visites

J'aime

Commentaires0

Veuillez vous connecter pour lire ou ajouter un commentaire

Articles suggérés

Articles Revue TELECOM

Quels rôles jouent les technologies numériques dans l’évolution de la médecine du travail ? Groupe Santé#196

photo de profil d'un membre

Rédaction Revue TELECOM

01 avril

Articles Revue TELECOM

Le numérique au service de la décarbonisation #196

photo de profil d'un membre

Rédaction Revue TELECOM

01 avril

Articles Revue TELECOM

DC Brain nommé au prix de la croissance #196

photo de profil d'un membre

Rédaction Revue TELECOM

01 avril