Le monde a sensiblement changé pour les entreprises utilisant des applications métier basées sur le web dans des environnements professionnels. La complexité des applications modernes – qui intègrent des architectures multi-tiers distribuées à l’échelle internationale et des SOA, et qui hébergent d’autres technologies nouvelles – a forcé les entreprises à repenser la manière dont elles développent, testent et gèrent les applications web. Les technologies d’applications internet riches (RIA) telles qu’Adobe Flex permettent une expérience plus rapide, plus conviviale et plus interactive grâce aux applications et aux services web. Bien qu’elles constituent un moyen attractif de développer des applications aux capacités étendues, ces technologies RIA présentent de nouveaux challenges pour les entreprises qui doivent déployer des modules et des fonctions dans un laps de temps restreint et à moindre coût. Par Christophe Marton, Software Architect, Neotys.

Le monde a sensiblement changé pour les entreprises utilisant des applications métier basées sur le web dans des environnements professionnels. La complexité des applications modernes – qui intègrent des architectures multi-tiers distribuées à l’échelle internationale et des SOA, et qui hébergent d’autres technologies nouvelles – a forcé les entreprises à repenser la manière dont elles développent, testent et gèrent les applications web. Les technologies d’applications internet riches (RIA) telles qu’Adobe Flex permettent une expérience plus rapide, plus conviviale et plus interactive grâce aux applications et aux services web. Bien qu’elles constituent un moyen attractif de développer des applications aux capacités étendues, ces technologies RIA présentent de nouveaux challenges pour les entreprises qui doivent déployer des modules et des fonctions dans un laps de temps restreint et à moindre coût.

Ces nouvelles technologies impactent naturellement  les entreprises doivent également adapter leur approche en matière de test. Etant donnée la manière dont les nouvelles technologies fonctionnent lorsqu’elles sont déployées sur des applications internet ou intranet, il est important de porter une attention spécifique sur le test des applications Flex.  Lorsque l’on déploie des applications de prochaine génération sur une plateforme applicative vitale pour le bon fonctionnement de l’entreprise, il est essentiel  d’être confiant dans les performances de ses systèmes. Le test de charge étant l’une des dernières étapes cruciales avant de lancer une application web, elle est généralement effectuée sous pression et avec des contraintes de temps importantes. Avant d’aborder les conseils qui vous permettront de réaliser avec succès le test de charge des applications Flex, penchons-nous d’abord sur ce qui rend ces dernières uniques.

Les applications Adobe Flex peuvent différer des applications avec lesquelles vous avez l’habitude de travailler. Pour les applications web HTML classiques, le serveur effectue l’ensemble du traitement, et le rendu du HTML nécessite un rafraîchissement de la page entière. Ces applications téléchargent l’application cliente Flash et fonctionnent dans un navigateur – ou, pour les applications Adobe AIR®, sur un poste de travail. Le Flash est mise à jour en permanence par le serveur, de manière asynchrone. Pour cette raison, les charges de serveur Adobe Flex ont un profil très différent.

Nous savons tous qu’il est important de mesurer les temps de réponse des transactions lorsque l’on veut tester des applications web. Mais la technologie Flex peut générer une augmentation importante du nombre d’appels entre navigateur et serveur HTTP, ce qui peut avoir de profonds impacts sur les performances. Alors que les utilisateurs ne sont pas forcément conscients des échanges entre le navigateur et le serveur distant, ils seront en revanche très sensibles aux problèmes de performance si l’application est lente ou génère des erreurs à cause d’une augmentation de charge. Connaitre les limites d’évolutivité des applications que vous déployez est crucial. 

Les technologies RIA innovantes comme Flex présentent de nouveaux challenges relatifs à la simulation d’une charge réaliste. Si vous développez ou déployez des applications basées sur cette nouvelle technologie, il sera indispensable de concevoir le test de charge différemment afin de répondre positivement à ces challenges. Voyons quels sont ces nouveaux challenges liés au test de charge des applications Flex, ainsi que trois conseils pour améliorer les performances applicatives et enrichir l’expérience utilisateur.

Conseil n°1 : Assurez-vous que vous pouvez décoder AMF et traiter les identifiants internes

Le protocole AMF (Action Messaging Format) d’Adobe Flex est utilisé pour échanger des données entre une application Adobe Flash et une base de données, en utilisant un appel Remote Procedure. Puisque les données sont sous un format binaire compressé, la communication est plus rapide et plus efficace qu’avec un service web. Les solutions de test de charge d’ancienne génération annoncent pouvoir prendre en charge la technologie « Flex », mais ont des difficultés à le faire dans le monde réel. De nombreux outils de test de charge s’appuient sur les données envoyées via http, mais n’utilisent pas le protocole AMF. Par conséquent, ils ne vont pas suffisamment en profondeur pour comprendre ce qui est échangé entre le client et le serveur. Pour un test optimum, assurez-vous que votre outil de test de charge décode ces objets, afin de vous permettre de paramétrer la requête, extraire les données de la réponse et valider la réponse.

De plus, le protocole de message AMF utilise des identifiants internes (clientld, DSld, etc.) pour maintenir une session AMF. Les paramètres dans une session AMF sont générés dynamiquement et sont nombreux. Pour éviter une configuration manuelle fastidieuse de ces paramètres, assurez-vous que votre outil de test de charge traite automatiquement les objets et les identifiants sérialisés.

Conseil n°2 : Assurez-vous que vous pouvez supporter les messages externes personnalisés

Le format binaire compact AMF3 permet d’intégrer des échanges de données binaires dans les plateformes de serveur. Le protocole améliore la qualité de toutes les commandes et solutions de messagerie pour Flex et optimise l’échange de données. AMF3 réduit la quantité d’information échangée et évite les messages redondants. En particulier, les messages externalisables AMF3 permettent aux développeurs de personnaliser la sérialisation des objets échangés dans AMF.

Lorsque vous sélectionnez un outil de test de charge, assurez-vous qu’il vous permet d’intégrer le code personnalisé. Pour un test optimum, le code personnalisé doit être chargé et exécuté par l’outil de test afin de rejouer correctement les messages client.

Conseil n°3 : Assurez-vous que vous pouvez supporter le polling et le streaming

De nombreuses applications Flex nécessitent que certaines données soient régulièrement envoyées depuis le serveur vers le client. Les serveurs utilisant le protocole AMF mettent à jour les données clients de deux manières :

1. 1.    La méthode du polling : Elle est utilisée lorsque le navigateur fait des requêtes auprès du serveur à intervalles réguliers. Techniquement simple dans sa mise en place, le mauvais côté de la méthode est qu’elle surcharge inutilement le serveur et n’est pas très réactive. Lorsque ces applications sont enregistrées avec un outil de test de charge, un grand nombre de requêtes navigateur-serveur sont enregistrées avec d’autres requêtes plus significatives. Il est donc important de s’assurer que votre outil peut simplifier automatiquement vos enregistrements afin de disposer d’un script clair et facile à faire évoluer.
2. 2.    La méthode du streaming : Dans ce cas, le client envoie une requête unique au serveur et le serveur répond lorsque l’information pertinente est disponible, sans clore la requête. Le serveur peut envoyer l’information au client une nouvelle fois  avec la même connexion, sans avoir à attendre une nouvelle requête. En utilisant cette méthode, les données client peuvent être rapidement mises à jour tandis que le trafic sur le réseau est maintenu à son minimum. L’outil de test doit être capable de maintenir le flux ouvert lorsqu’il joue une requête de streaming. Cette requête va bloquer la connexion courante, l’outil doit donc être capable d'utiliser une seconde connexion en parallèle pour les requêtes classiques.

Dans les deux cas, les temps de réponse HTTP classiques ne sont pas utiles. Pour les requêtes HTTP usuelles, les outils de test de charge mesurent le délai entre le moment où la requête est envoyée et le moment où la réponse est reçue. Il est important que votre outil de test de charge puisse mesurer ce qui est réellement intéressant : le délai entre le moment où le serveur met à jour le client et le moment où le client reçoit la mise à jour. Non seulement l’outil doit mesurer cette information, mais cette fonction doit également être automatisée afin que le test puisse être effectué fréquemment et tôt dans le cycle de vie de l’application.

Alors que de plus en plus d’entreprises déploient sur internet des applications essentielles à leurs activités, il est devenu très important de tester les performances de ces applications web et mobiles selon différents scénarios de charge  avant de les mettre en production. Tandis qu’Adobe Flex fournit des capacités étendues pour développer de nouvelles applications plus puissantes répondant aux besoins métier des entreprises, la technologie diffère des autres applications. Par conséquent, une nouvelle approche du test de charge est nécessaire. Pour comprendre comment vos applications fonctionneront dans un environnement de production Adobe Flex, et pour en optimiser les performances, vous avez besoin de pouvoir simuler non pas les actions d’un utilisateur unique, mais celles de multiples utilisateurs. Les conseils donnés dans cet article peuvent permettre aux entreprises d’adapter rapidement leur méthodologie de test pour les applications Flex, les mettre plus rapidement et plus facilement sur le marché, tout en améliorant la productivité et réduisant les coûts.

Christophe Marton, Software Architect et cofondateur, Neotys

Diplômé de l’ESIL Marseille en Ingénierie Informatique, Christophe Marton est cofondateur de Neotys et co-créateur du logiciel NeoLoad. Il a commencé sa carrière chez Calendra, éditeur de solutions de gestion des identités racheté par BMC Software en 2005. Au cours des six années passées chez Calendra, il a développé les compétences nécessaires pour créer, développer et mettre sur le marché des logiciels de pointe. Son expérience chez Calendra lui a permis de se confronter aux problèmes de performance et au domaine du test en charge pour lequel il a développé une vision unique pour une solution de prochaine génération. Il a quitté Calendra pour cofonder Neotys et faire de cette vision une réalité avec le développement de NeoLoad.