Mesures de performance pour la communication inter-processus

SEG-2506 - (Lab-11 en 2013) - Lab 10 en 2015 and 2016

Ce laboratoire traite des problemes de performance. Votre travail consiste à évaluer, mesurer et comparer les performances de plusieurs versions de programmes, tous suivant le même schéma de conception générale.

Description du système de haut-niveau

Nous considérons une application simple où un producteur envoie des données à un consommateur. Les données sont regroupées en «messages» qui sont envoyés séparément. Chaque message consiste d'un tableau d'objet de type Employee (de longueur messageSize) et le nombre de messages transmis (repititions). Votre tâche consiste à mesurer le temps necessaire pour transmettre N objets du producteur au consommateur utilsant les versions différentes des programmes et des environnements d'exécution différents. Note: N = messageSize * repetitions.

Toutes les versions de programmes ont l'architecture suivante: Il ya un thread producer et un thread consumer. Le producer génère des objets Employee aléatoires et les place dans le tableau d'un message. Puis il "envoie" le message aux consumer. Lorsque le consumer "reçoit" un message, il consomme le message (i.e il lit les informations des objets) et envoie un accusé de réception (acknoweldgment) au consumer. Le consumer attend la réception de l'accusé (acknoweldgment) avant de préparer le prochain message.

Le système contient aussi un module appelé communication. C'est un module qui fournit des méthodes pour envoyer et recevoir des messages. Les versions différentes du programmes diffèrent dans la façon dont le module de communication est mis en œuvre. Les versions suivantes sont prévues:

  1. CommSimple (communication simple): un seul Employee [] structure des données est fourni par le module de communication. Les données sont directement placés dans cette structure de données par le producteur et sont lues par le consommateur directement à partir de la même structure sans les copier. Deux semaphors sont utilisés pour contrôler la synchronisation: le sémaphore envoyé (sent) permet au récepteur de consommer le message et le sémaphore reçu (received) autorise le producteur à préparer le contenu du message suivant.

  2. CommCoded (communication encodée): Notez que pour toutes les versions, le producteur et le consommateur voient la même interface du module de communication. Dans cette version, le message transmis par le producteur est encodé comme une chaîne de texte dans une seule Java String. Cette String est décodé lorsque le consommateur reçoit le message, de telle sorte que le destinataire reçoit le tableau des objets originaux établi par le producteur. On peut s'attendre à ce que le temps d'exécution de cette version est plus lente à cause de l'encodage et le décodage et la copie des données correspondante.

  3. CommByFile: Cette version encode la séquence des objets Employee, mais au lieu de placer le résultat dans une variable de type String, cette version écrit la chaîne de caractères dans un fichier qui est fermé lorsqu'il contient un message complet. Le même fichier est lu par le consommateur quand il reçoit le message.

  4. CommByTCP (communication par TCP): Dans cette version, chaque message codé est envoyé comme une chaîne de caractères à travers une connexion TCP vers le consommateur. Il ya deux programmes Java "main": CommByTCP_sender et CommByTCP_receiver. Le programme expéditeur utilise un Socket et établit d'abord une connexion avec le programme de récepteur. Celui-ci utilise une Socket sur lequel il commence l'écoute. Une fois la connexion établie, les programmes fonctionnent un peu comme les versions 2 et 3. Notez, cependant, que la synchronisation entre le producteur et le consommateur (fourni par le module de communication), dans cette version, n'utilise pas les sémaphores, mais la transmission du messages. Lorsque le consommateur exécute la sendAck () méthode, une simple séquence Acknowlegement message sera envoyé au producteur.
  5. Two variants of CommCoded were originally planned as well: CommCoded-JavaSerialization and CommCoded-XML. However the TA did not have enough time to prepare the Java programs for these examples. The purpose of these two variants would have been to compare the performance of XML and Java-Serialization encoding with the straightforward String encoding implemented in version 2 above and used in version 4.

Voici les programmes Java. Notez que pour chaque version du programme, il ya une version du module de communication (appelé CommXXX) et une version du programme principal Java (appelée Producer_Consumer_System). Vous pouvez modifier la longueur du tableau d'entier et le nombre de messages en modifiant les constantes de la classe Producer_Consumer_System. Le thread de producteur s'attend au début que l'utilisateur entre un Carriage Return (ENTER) pour commencer ses opérations. Il calcule le temps total requis pour ses opérations.

Notez que les classes CommByFile, CommByTCP_sender and CommByTCP_receiver ne sont pas données. Vous devriez les écrire en utilisant certaines parties de la classe CommCoded. Voici quelques suggestions.

Voici des notes d'implantation préparée par Salman Hooshmand (TA en 2015).

Vos tâches:

  1. Exécuter 10 fois la version courant de la classe Producer_Consumer_System du programme pour mesurer le temps d'exécution du programme (utilisant la CommSimple classe). Notez les 10 valeurs obtenues.
  2. Mettez d'autres charges sur l'ordinateur - des traitements lourdes (par exemple l'affichage d'une vidéo, l'ouverture d'un gros fichier sous Word). Utilisez l'Analyseur de performances Windows (sous le panneau de contrôle administratif) pour voir le niveau d'utilisation des ressources de l'ordinateur pendant l'exécution de votre programme Java seul, au cours de l'exécution des tâches lourdes seules, et lorsque le programme Java est exécuté pendant du traitement lourd. Mesurer le temps d'exécution de notre programme Java et de discuter les résultats obtenus en tenant compte des indications de performance Window observé. Vous pouvez également introduire plusieurs DummyThreads dans le programme principal Java. - Comment la performance varie quand vous faite ces changements ? - Expliquer ce que vous avez trouvé.
  3. Utiliser la version CommCoded du programme Java et répèter les mesures du point (1). Calculez la moyenne des mesures et l'erreur attendue de la moyenne. Comparez le temps d'exécution avec la version CommSimple et tentez d'expliquer vos résultats.
  4. Utiliser la version CommByFile du programme Java et répèter les mesures du point (2). Comparer le temps d'exécution avec la version CommCoded et tenter d'expliquer vos résultats. Quelle est la performance de l'écriture et lecture du fichier par rapport à la performance du codage-décodage ?
  5. Essayer d'utiliser différentes tailles des messages (messageSize). Conserver le même nombre total d'objets à être transférés. Mesurer le temps d'exécution pour de nombreuses valeurs de taille de message messageSize et faire un diagramme du temps d'exécution en fonction du nombre de messages transférés. Expliquez vos résultats.
  6. Completer la version CommByTCP du programme Java (où il y a deux versions du module communication, un pour le sender qui demande l'établissement d'une connection au receiver, et un pour le receiver qui accepte cette demande de connection) et répéter les mesures du point (3) en exécutant le sender et le receriver dans la même machines virtuelle sur votre ordinateur. (Vous pouvez aussi partitionner le programme en deux et les exécuter sur deux ordinateurs différents, si vous voulez). Encore une fois, mesurer le temps d'exécution avec des tailles de message différentes (comme sous le point 6 5). Expliquez vos résultats. Note: Vous pouvez trouver un tutoriel sur l'utilisation de classes Socket en Java chez Sun (Oracle). Voici un exemple de deux programmes, client et serveur. Le client établit une connection TCP vers un server, et le serveur retourne le texte reçu du client vers le client.

À montrer au TA (ceci est un lah informel):


Merci à Ahmed Jeddah pour cette traduction de l'anglais (21 mars, 2010); dernière mise à jour: 1er avril 2016