Adaptation et expérimentation de l algorithme des trains dans le contexte des centres de données géorépliqués

Transcription

1 Adaptation et expérimentation de l algorithme des trains dans le contexte des centres de données géorépliqués dans le Cloud Etudiants : Trong Lam PHAN, Yaxiong OU Encadrant : Mr. Michel SIMATIC Octobre 2014 Janvier 2015

2 Remerciements Nous tenons à remercier très sincèrement et à exprimer notre gratitude à tous ceux qui ont contribué à la réalisation du projet «des trains» depuis le début, plus particulièrement notre encadrant M. Michel SIMATIC qui nous a suivi tout au long de ce projet et nous a beaucoup aidé dans nos nombreux questionnements. Ses conseils avisés ont participé au bon déroulement de notre projet. Nous voudrons également envoyer nos remerciements à tous les professeurs de Télécom SudParis qui nous ont fourni des connaissances précieuses. Cela nous a permis de bien effectuer ce projet. 1

3 Table des matières I. Introduction... 5 a. Protocole des trains... 5 b. Intuition... 6 II. Algorithme... 6 a. Uniformité... 6 b. Non Uniformité à ordre total... 6 c. Causalité Twitter... 6 III. Environnement, Outils, API... 7 a. Outils de test de montée en charge Gatling... 7 b. Amazon Web Service... 7 c. Netperf... 7 d. ZeroMQ... 7 IV. Mesures de performance du protocole «des trains»... 8 a. Scénario des mesures... 8 b. En local... 9 c. Dans le cloud... 9 V. Applications Clients a. Twitter b. Zamazon VI. Résultat de test des applications VII. Conclusion VIII. Bibliothèque

4 Liste des figures Figure 1 : Centre de données géo-répliqués (Willy Zwaenepoel)... 5 Figure 2 : Architecture de ZeroMQ... 8 Figure 3 Architecture de l application Twitter dans le Cloud Figure 4 : Logo de l application Zamazon Figure 5 : Architecture de la base de données de l application Zamazon Figure 6 : Architecture du système de l application Zamazon Figure 7 : Capture d écran de la page d accueil de l application Zamazon Figure 8 : Capture d écran de la page de la consultation de l application Zamazon Figure 9 : Capture d écran de la page d achat de l application Zamazon Figure 10 : Architecture de la réplication des données de l application Zamazon Figure 11 : Résultat du test en boucle de 100 fois en utilisant Gatling Figure 12 : Résultat du test en boucle de 200 fois en utilisant Gatling Figure 13 : Résultat du test en boucle de 1000 fois en utilisant Gatling Figure 14 : Erreur au cas où on utilise une boucle de 1000 fois Liste de tableaux Tableau 1 : Résultat du test en C en local... 9 Tableau 2 : Résultat de la mesure «latence» en utilisant Netperf Tableau 3 : Résultat du test en C dans le Cloud AWS sur le circuit optimal en termes «latence» Tableau 4 : Résultat du test en Java dans le Cloud AWS sur le circuit optimal en termes «latence» Tableau 5 : Résultat de la mesure du débit en utilisant Netperf Tableau 6 : Résultat du test en C dans le Cloud AWS sur le circuit optimal en termes «débit» Tableau 7 : Résultat du test en Java dans le Cloud AWS sur le circuit optimal en termes «débit»

5 Résumé Dans le cadre du projet de fin d études, on a travaillé sous la supervision de M. Michel SIMATIC depuis Octobre 2014 jusqu à la fin du mois de Janvier Notre projet est un héritage de plusieurs projets déjà réalisés. Le protocole du projet s appelle «des trains» est commencé par M. SIMATIC en 2012 et développé par plusieurs anciens élèves. Ce protocole est conçu pour être un protocole efficace en termes de débit pour des petits clusters et des messages courts. Actuellement, la performance du protocole est prouvée d avoir un rendement supérieur au meilleur, en termes de débit, des protocoles présentés dans la littérature. Cependant, M. SIMATIC pense que le protocole pourrait devenir plus efficace si on concilie la performance et la qualité de la cohérence du protocole en retirant la propriété d uniformité. L objectif de ce projet est de vérifier cette intuition. Voici les tâches qu on a finies dans le cadre du projet : - Améliorer le protocole en retirant la propriété d uniformité. Programmer en langage C. - Développer l outil de test de latence en Java. - Mesurer la performance de l algorithme «non_uniforme» dans le Cloud Amazon Web Services (AWS) en considérant une application répliquée sur Frankfurt, California, Tokyo et Sao Paulo. Ces tests sont réalisés en C et en Java. - Développer une application en Java jouet de vente par internet qui s appelle Zamazon. Cette application est reposée sur l interface Java programmée par deux anciennes élèves. Cette interface permet d interagir avec le protocole en C mais utiliser le langage Java. - Enlever l ordre total du protocole mais garder l ordre causal que on s appelle «Causalité Twitter» pour servir aux cas concrets comme : Twitter, Facebook. Développer un outil de test en C et en Java, qui permet de tester le protocole en local et dans le cloud Amazon. - Développer une application Twitter avec l interface client qui déploie l algorithme «Causalité Twitter» et qui dispose deux fonctions de base de la vraie application : o Afficher des tweets dans la base de données. o Répondre à un tweet. - Mesurer la performance de l application Twitter en utilisant l outil de test Gatling dans le Cloud Amazon Web Services. 4

6 I. Introduction a. Protocole des trains Il y a de nombreuses applications qui sont actuellement géo-répliquées dans le Cloud : une instance d'application munie d'une copie de l'ensemble des données de l'application s'exécute aux USA, pendant qu'une autre instance (et sa copie des données) s'exécute en Europe, pendant qu'une autre instance s'exécute en Chine, etc. Figure 1 : Centre de données géo-répliqués (Willy Zwaenepoel) Quand un client souhaite accéder à une instance d'applications, il est dirigé vers l'instance géographiquement la plus proche pour éviter des temps de latence trop longs. Et, quand ce client modifie des données au niveau de cette instance, ces mises-à-jour doivent être répercutées de manière cohérente sur l'ensemble des instances. Répondre à ce besoin de cohérence est un problème difficile. Actuellement, les industriels (Google, Amazon) et la communauté scientifique proposent de s'appuyer sur certains protocoles (exemple : famille de protocole Paxos) pas assez performants dans un contexte Cloud pour certaines applications, ou bien de réduire les ambitions de cohérences (en se contentant, par exemple, d'une eventual consistency) pour préserver les performances. Le protocole des trains est inspiré de l idée du protocole du train de [Cristian, 1991]. Dans un petit cluster de machines interconnectées, le protocole des trains s'exécute par un réseau. Plusieurs trains qui portent des messages, circulent en parallèle entre n processus participants répartis selon un anneau virtuel. Chaque processus participe au protocole, a une connexion TCP ouverte avec son prédécesseur et une autre connexion TCP ouverte avec son successeur sur cet anneau. Sur chacune de ces connexions TCP, les messages circulent en général toujours dans le même sens. 5

7 Un train est un jeton qui circule sur un anneau virtuel. Il transporte les messages à diffuser au sein de wagons. Un wagon est une structure de données qui permet de stocker les messages à diffuser. Quand un processus p souhaite diffuser un message m, p ajoute m à un wagon w. Ce wagon w est ajouté en queue du premier train qui passe. Il y a deux versions du protocole des trains : mono-train et multi-trains. Dans ce rapport, on présente seulement l algorithme multi-trains qu on a appris et utilisé au cours du projet. b. Intuition En simplifiant l'algorithme des trains pour supprimer la propriété d'uniformité et aussi l ordre total de sa diffusion, nous pensons que cet algorithme peut concilier performance et qualité de la cohérence. L'objectif de ce projet ASR est de vérifier cette intuition. II. Algorithme a. Uniformité La contrainte d uniformité est garantie par deux propriétés d ordre : l ordre FIFO et l ordre causal. Elle garantit que dès qu un processus uot-livre un message, in fine tous les processus l uot-livereront. L ordre FIFO : «Si un processus correct diffuse un message m avant de diffuser un message m, alors aucun processus correct ne livre m avant d'avoir au préalable livré m». (Ordre FIFO [Hadzilacos et Toueg, 1994]) L ordre causal : «Si la diffusion d'un message m précède causalement la diffusion d'un message m, alors aucun processus correct ne livre m avant d'avoir livré m au préalable». (Ordre causal [Hadzilacos et Toueg, 1994]) La garantie de la propriété «uniforme» cause une diminution des performances. Elle demande des ressources supplémentaires (CPU, mémoire et réseau). De plus, le temps écoulé entre l uot-diffusion du message par un processus et son uot-livraison par les différents processus est allongé. En effet, le protocole d uot-diffusion doit garantir que tous les processus participant au protocole ont reçu le message et sont prêts à l uot-livrer. b. Non Uniformité à ordre total La propriété d uniformité concerne l ensemble des processus, ceux qui sont corrects et ceux qui ont défailli. Pour la propriété de non-uniformité à ordre total, si un processus p2 diffuse un message m et il est mort, on ne peut pas assurer que tous les processus (p2 inclus) ont reçu le message m. La propriété «non_uniformité» est alors bien moins fort que la propriété «uniformité» mais dans plusieurs cas actuels, on peut la mettre en pratique avec aucun problème. c. Causalité Twitter 6

8 Dans ce cas, on respecte l ordre causal mais on ne respecte plus l ordre total. Un processus p1 diffuse un message m1 et ensuite, un message m2, c est possible que le processus p2 délivre m2 avant m1 (m2 ne dépend pas causalement de m1). Mais si la diffusion d un message m1 précède causalement de la diffusion d un message m2, aucun processus correct alors délivre m2 avant d avoir délivré m1. III. Environnement, Outils, API a. Outils de test de montée en charge Gatling Gatling est un outil de test de montée en charge gratuit et open source. Gatling permet de simuler un nombre d utilisateurs à partir d une seule machine, consistant à communiquer par échanger de messages asynchrones. Gatling est fiable, puissante et facile à alimenter et il permet d étudier les performances d applications web. Pour mettre en œuvre des requêtes de manière optimale, Gatling s appuie sur la librairie Asynchronous HTTP Client et sur le framework Netty. Cet outil permet également de générer un ensemble de pages HTML pour afficher les rapports de tests. Afin de produire des graphiques de manière optimisée, il repose sur les librairies javascript highstock et highcharts. b. Amazon Web Service L Amazon Web Service regroupe plusieurs services proposés en ligne. Pour ce projet, on a utilisé un des services les plus connus : EC2. EC2 (Amazon Elastic Compute Cloud) permet de louer des machines virtuelles qui peuvent être configurées et pilotées en ligne. Ces infrastructures informatiques fournissent de la puissance de calcul «depuis les nuages» qui est destinée aux développeurs. Ce service est conçu pour faciliter l accès aux ressources de cloud computing à l échelle du Web. Puisque nos tests sont temporaires dans le Cloud, c est la raison pour laquelle on a utilisé EC2. c. Netperf Netperf est un logiciel libre permettant de simuler du trafic entre deux points d'un réseau. NetPerf permet de simuler des transactions TCP et UDP du transfert de données. NetPerf permet de mesurer le débit de notre réseau, c'est à dire la quantité des données que l'on peut transporter en une seconde d'une machine vers une autre. d. ZeroMQ ZeroMQ est une API de files d attentes basée sur des sockets TCP et conçue spécialement pour des applications à hautes performances et faible latence. Cette API est en mode «sans broker». L objectif de cette API est de concevoir une API de Messaging conçue pour des applications de micro-trading haute fréquente. 7

9 Les points forts de ZeroMQ sont ses performances et sa fiabilité. Sa taille est très réduite et ses performances sont hors normes. L'inconvénient évident est qu'il y a davantage de travail nécessaire pour l'intégrer dans une application. Une clé de ZMQ est de ne pas utiliser de mécanisme de synchronisation: les sockets ZMQ ne sont pas thread-safe. Un même socket ne donc doit pas être utilisé par deux threads différents. Les échanges entre deux sockets sont asynchrones et se font par messages. Voici l architecture de ZeroMQ : Figure 2 : Architecture de ZeroMQ Entre deux processus, il y a un socket qui transporte des messages. Le «Directory Service» fait la gestion des adresses de tous les processus. IV. Mesures de performance du protocole «des trains» a. Scénario des mesures En gardant le débit approximatif égal, les mesures nous permettent de comparer la latence de chaque algorithme «uniformité», «non_uniformité» et «causalité twitter». Pour les deux premiers tests «uniformité» et «non_uniformité à ordre total», on a réalisé des tests de type PING_PONG, c est-à-dire que le processus p diffuse un message PING avec son temps d envoi au réseau, quand ce processus p délivre le message PING, il n enregistre pas encore la latence du message, mais il continue à diffuser une copie du message PING que l on s appelle PONG qui prend le temps d envoi du message PING au lieu de son temps d envoi propre. Quand ce processus p délivre le message PONG, il compte l intervalle depuis le temps d envoi du message PING jusqu au temps de livraison du message PONG comme la latence du message PING. Avec cette méthode, on peut savoir la latence d un message PING 8

10 et bien sûr également, en fin, la latence moyenne de tous les messages diffusés par le processus p. Pour le test «causalité twitter», on mesure trois propriétés : la latence, le débit et l overhead (le temps entre le temps d envoi du message provenant d un processus et le temps où le premier train qui passe). Le processus p diffuse un message m, quand un train t arrive au processus p, ce processus délivre ce message m toute de suite. Les autres processus délivrent également ce message m quand le train t arrive chez eux. La latence alors est l intervalle entre le temps d envoi du message m et le temps le train t finit un tour et retourner au processus p. b. En local En local, on fait un test sur deux, trois et quatre machines. Uniformité Latence (ms) Débit Non uniformité Latence (ms) Débit Causalité Overhead (ms) Latence (ms) Débit Tableau 1 : Résultat du test en C en local Le résultat répond à notre attente. En gardant le débit approximatif égal : Latence «Uniformité» 1.6 * latence «Non_Uniformité» 2.8 latence «Causalité» c. Dans le cloud Dans le Cloud AWS, on fait également un test sur deux, trois et quatre machines à Frankfurt, California, Tokyo et Sao Paulo. Pour nos tests, le circuit commence toujours par la machine à Frankfurt. Grâce à l outil NetPerf, on est capable de mesurer le débit et la latence entre les quatre machines pour choisir un circuit optimal à notre objectif. i. Circuit par rapport à la latence Voici le résultat de la mesure «latence» entre les quatre machines en utilisant Netperf : 9

11 Sao Paulo California Tokyo Frankfurt Sao Paulo California Tableau 2 : Résultat de la mesure «latence» en utilisant Netperf Ce résultat nous permet de spécifier le circuit optimal en termes de «latence» : - Avec deux machines de Frankfurt et de Sao Paulo : on a un seul circuit : Frankfurt Sao Paulo. - Avec trois machines de Frankfurt, de Sao Paulo et de California : le circuit optimal est : Frankfurt California Sao Paulo. - Avec quatre machines de Frankfurt, de Sao Paulo, de California et de Tokyo : le circuit optimal est : Frankfurt California Tokyo Sao Paulo. Test en C Uniformité Latence (ms) Débit Non uniformité Latence (ms) Débit Causalité Overhead (ms) Latence (ms) Débit Tableau 3 : Résultat du test en C dans le Cloud AWS sur le circuit optimal en termes «latence» Le résultat répond à notre attente. En gardant le débit approximatif égal : Latence «Uniformité» 1.78 * latence «Non_Uniformité» 2.87 latence «Causalité» Test en Java Uniformité 10

12 Latence (ms) Débit Non uniformité Latence (ms) Débit Tableau 4 : Résultat du test en Java dans le Cloud AWS sur le circuit optimal en termes «latence» Le résultat répond à notre attente. En gardant le débit approximatif égal : Latence «Uniformité» 1.5 * latence «Non_Uniformité» i. Circuit par rapport au débit Voici le résultat de la mesure «débit» entre les quatre machines en utilisant Netperf : Sao Paulo California Tokyo Frankfurt Sao Paulo California 8.81 Tableau 5 : Résultat de la mesure du débit en utilisant Netperf Ce résultat nous permet de spécifier le circuit optimal en termes de «débit» : - Avec deux machines de Frankfurt et de Sao Paulo : on a un seul circuit : Frankfurt Sao Paulo. - Avec trois machines de Frankfurt, de Sao Paulo et de California : le circuit optimal est : Frankfurt Sao Paulo California. - Avec quatre machines de Frankfurt, de Sao Paulo, de California et de Tokyo : le circuit optimal est : Frankfurt Tokyo Sao Paulo California. Test en C Uniformité Latence (ms) Débit Non uniformité Latence (ms) Débit

13 Causalité Overhead (ms) Latence (ms) Débit Tableau 6 : Résultat du test en C dans le Cloud AWS sur le circuit optimal en termes «débit» Le résultat répond à notre attente. En gardant le débit approximatif égal : Latence «Uniformité» 1.74 * latence «Non_Uniformité» 2.75 latence «Causalité» Test en Java Uniformité Latence (ms) Débit Non uniformité Latence (ms) Débit Tableau 7 : Résultat du test en Java dans le Cloud AWS sur le circuit optimal en termes «débit» Le résultat répond à notre attente. En gardant le débit approximatif égal : Latence «Uniformité» 1.5 * latence «Non_Uniformité» En résumé, avec le débit approximatif égal, la latence «uniformité» est toujours supérieur à la latence «non_uniformité» et bien supérieur à la latence «causalité». V. Applications Clients a. Twitter Application Twitter est une application qui permet d envoyer et de recevoir des tweets entre les machines dans le Cloud. Il contient l application serveur et l application client. Associée avec le system de TrainsProtocol montré par la figure ci-dessous, on peut mesurer la performance en termes de débit et de latence du protocole des trains «causalité» : 12

14 Figure 3: Architecture de l application Twitter dans le Cloud Quand un client ajoute un tweet, il envoie une requête «addtweet» (1-1) au Twitter Web App. Cette requête est transférée (1-2 et 1-3) au TrainsProtocol par ZeroMQ. Le TrainsProtocol délivre ce nouveau tweet quand il y a un train qui passe. Il envoie une réponse (2-1, 2-2) au Twitter Web App par ZeroMQ. Le Twitter Web App ajoute ce nouveau tweet dans la base de données (2-3) et répond au client (2-4) avec un statut «success». En même temps, le TrainsProtocol diffuse ce nouveau tweet dans le Cloud, un train qui porte ce tweet circule de Frankfurt à California (3-1), de California à Tokyo (4-1) et de Tokyo à Sao Paulo (5-1). Pour montrer comment ça marche sur une instance (sauf Frankfurt c est celui qui diffuse ce tweet), sur la figure 3, on détaille le processus sur la machine à Tokyo. Le TrainsProtocol reçoit le tweet et le délivre toute de suite en envoyant à TwitterSync par ZeroMQ (4-2, 4-3). Le TwitterSync est un programme Java qui permet de recevoir des nouveaux tweets délivrés et les mettre dans la base de données. Le client met à jours son affichage en faisant un «gettweet» qui le permet de récupérer tous les tweets dans la base de données de façon structurée. b. Zamazon i. Présentation de l application 13

15 Après on voit la performance dans le Cloud Amazon Web Services(AWS), on essaie de concevoir une application qui s'appuie sur l'interface Java de l'algorithme des trains pour diffuser les mises-à-jour faites sur la base de données d'une instance. Zamazon est une application client-serveur qui permet d acheter des produits sur le serveur. Le nombre de produits doit être identique sur toutes les instances dans le Cloud. Figure 4 : Logo de l application Zamazon i. Des fonctionnalités réalisées Des utilisateurs peuvent accéder et visiter le site «ZAMAZON» en utilisant ses navigateurs, et les deux fonctionnalités simples qu'on veut réaliser sont de «consulter la quantité des produits», et «faire l'achat». Par un identifiant de produit, des utilisateurs peuvent choisir des actions qu'il veut. i. Conception de base de données Entre le serveur et la base de données, des actions «consulter la quantité des produits» et «faire l'achat» peuvent être décrites comme des requêtes SQL «Select» et «Update». Un produit enregistré dans un tableau de la base de données se compose de deux propriétés «Référence» et «Quantité». Et la «Référence» est la clé primaire intuitivement, selon la référence, on peut faire des actions. Figure 5 : Architecture de la base de données de l application Zamazon 14

16 Et au niveau du système de gestion des bases de données, on utilise MySQL pour le réaliser, sachant qu'il est multi-thread et multi-utilisateur et il peut fonctionner dans des différentes plateformes C, C ++, Java, Perl, PHP, Python etc. Le protocole de trains est réalisé en code JAVA, et on peut utiliser JDBC (Java DataBase Connectivity) qui est une interface de programmation pour accéder à la base de données et faire des requêtes SQL au niveau du code JAVA. i. Architecture de l application Sachant que la séparation client-serveur REST des préoccupations simplifie la mise en œuvre de composants, réduit la complexité de la sémantique des connecteurs, améliore l'efficacité de l'optimisation des performances, et augmente l'évolutivité des composants du serveur pures, on peut utiliser l'architecture RESTFUL pour la partie ZAMAZON. Parlant de REST, toutes les requêtes et réponses sont sur le «transfer of representations of resources», et il nous fournit quatre type d'opérations GET, READ,UPDATE et DELETE qui sont correspondant aux opérations créer, lire, mettre à jour, supprimer au niveau de base de données. Pour l'application ZAMAZON, on a besoin de récupérer la quantité des produits GET, faire l'achat PUT. Le problème apparaît lorsqu'on veut tester le REST sur un navigateur pour la méthode PUT, la plupart des navigateurs ne supporte pas l'action PUT de REST, mais on peut essayer de faire le GET qui fait quand même la mises-à-jour au niveau de base de données et retour un nouveau résultat de la quantité des produits qu'on veut acheter. Figure 6 : Architecture du système de l application Zamazon i. Démonstration La page d'accueil. 15

17 Figure 7 : Capture d écran de la page d accueil de l application Zamazon La page du retour de la consultation. Figure 8 : Capture d écran de la page de la consultation de l application Zamazon La page de faire l'achat et afficher la quantité restant. 16

18 Figure 9 : Capture d écran de la page d achat de l application Zamazon i. Réplication de base de données Sachant que des grandes entreprises B2C et C2C comme Amazon et Ebay ont des services de l'achat dans le monde, ces services sont souvent fourni dans des différent pays et régions et ainsi pour l'application ZAMAZON on a besoin de construire certains nombre de serveurs et base de données dans différents endroits. Et ces bases de données doivent être synchronisées ou répliquées. Souvent un serveur se trouve loin de l'autre, la transmission rapide des messages pour la synchronisation des bases de données est nécessaire. Figure 10 : Architecture de la réplication des données de l application Zamazon L'algorithme des trains est utile pour résoudre ce type de problème. Au niveau des serveurs, d'abord il reçoit une requête de HTTP, avant de faire la requête SQL, il le diffusera aux autres serveurs en protocole des trains et il attend que tous les serveurs ont reçus la diffusion de requête. Dans ce protocole, la méthode de CallBack sert à retourner le résultat et faire mises-à-jour de la base de données. Et il y a aussi de problème de synchronisation entre ces deux actions et on peut le résoudre en utilisant Sémaphore au niveau du code JAVA. 17

19 VI. Résultat de test des applications On a testé l application Twitter en utilisant l outil Gatling et le scénario qui déploie la structure montrée par la figure 1 : Il y a 4 serveurs à Frankfurt, Sao Paulo, California et Tokyo. Il y a 4 clients qui envoient à son serveur correspondant les requêtes HTTP. Un client envoie une requête «AddTweet» au serveur correspondant, puis, il attend la réponse du serveur, ensuite, il attend 1 milliseconde avant d envoyer une requête «GetTweets» au serveur. Après d avoir le résultat de la requête «GetTweets», il fait un délay 1 milliseconde avant de retourner au début de la boucle (c està-dire qu il continue à envoyer une requête «AddTweet»). Pour une boucle de 100 fois ou bien 200 fois, le système marche normalement mais 1000 fois, ça cause un problème du serveur glassfish dont sa queue de requête est remplie et le serveur glassfish est bloqué. Voici le résultat qui nous intéresse : i. Boucle de 100 fois (correspondant 200 requêtes par client) : Figure 11 : Résultat du test en boucle de 100 fois en utilisant Gatling Sur la figure 11, on peut voir que les 200 requêtes sont terminées sans problème. Le temps d attente moyen est de 199 ms, des requêtes «add_tweet» est de 376 ms et des requêtes «get_tweet» est de 22 ms. On peut voir également que de plus en plus, le temps augmente à cause du nombre de requêtes envoyées au serveur. 18

20 L overhead moyen dans le test ce qu on a montré sur 4 machines est de 86 ms. Sur l application, cette valeur est montée à 376 ms. On a l intuition que le serveur n est pas encore optimisé et le problème est sur des requêtes «INSERT» dans la base de données qui fait ralentir le système. i. Boucle de 200 fois (correspondant 400 requêtes par client) : Dans le cas 200 fois de boucle, l overhead des requêtes «add_tweet» du système (487ms) est supérieur à celui au cas où 100 fois de boucle (376ms). Figure 12 : Résultat du test en boucle de 200 fois en utilisant Gatling i. Boucle de 1000 fois (correspondant 2000 requêtes par client) : Dans ce cas, il y a seulement 51% des requêtes qui ont réussi. Les autres requêtes sont échouées à cause de la limite du serveur. Figure 13 : Résultat du test en boucle de 1000 fois en utilisant Gatling Les erreurs montrées ci-dessous nous permettent de savoir quels sont les erreurs rencontrées et les problèmes à résoudre dans le futur. 19

21 Figure 14 : Erreur au cas où on utilise une boucle de 1000 fois VII. Conclusion En résumé, ce projet de fin d études est une expérience très riche qui nous a permis d élargir notre champ de vision dans le monde informatique professionnel, nos connaissances et nos capacités. Il nous permet également de mettre en pratique les connaissances d ASR dans un projet concret. Nous sommes bien conscients d avoir eu de la chance de travailler sur ce projet. VIII. Bibliothèque - M. Simatic, Contributions au rendement des protocoles de diffusion à ordre total et aux réseaux tolérants aux délais à base de RFID, Thèse de doctorat, Conservatoire National des Arts et Métiers (CNAM), octobre Jean-Sébastien Mercy, Gatling, nouvelle solution libre pour les tests de montée en charge, le 20 Janvier Virgile Juhan, AWS : Amazon Web Services, l emblème du cloud computing, le 18 Sep ZeroMQ, The Guide 20