Chapitre III RMI : Remote Method Invocation
V- 3-4 Le Principe de test
L'appel de procédure distante comprend de nombreuses étapes et il permet de mieux comprendre ce qui est effectivement mesurée lors d'un appel de méthode, De telles mesures donneraient une idée claire de ce qui est passe sous le « capot »de CORBA, RMI et DCOM
Le modèle de calcul du temps est décrit pour un client qui fait une demande à un serveur. Le client est le passage de paramètres d'entrée à l'appel et le serveur fait un travail avant de retourner un résultat au client.
Suivant la figure :
t1 : désigne le temps juste avant que le client ne fasse la demande. t2 : désigne le moment où le client a reçu une réponse à sa demande.
La différence t2 - t1 est le temps de réponse de la demande, qui est aussi appelé temps de l'aller-retour, cette différence est donnée par:
tmarshalling(demande) : Le temps nécessaire pour permettre le rassemblement et la traduction des paramètres d'entrée et de mettre le demande sur le réseau.
tcommunication : Le temps nécessaire sur le réseau pour que la demande Voyagé du client vers le serveur et vice versa
tUnMarshalling(demande) :Le temps nécessaire pour recevoir et faire la traduction inverse de la demande.
texécution :Le temps d'exécution sur le serveur.
tMarshalling(résultat) :Le temps nécessaire pour que le serveur puisse rassembler les résultats et de sa mise sur le réseau.
tUnMarshalling(résultat) :Le temps nécessaire pour recevoir le résultat et le unmarshalling.
En fait la différence t2 - t1 est trop petite pour être mesurée sur une invocation. La solution à ce problème est de prendre le temps de plusieurs appels, ce qui signifie que l'horloge est démarrée avant la première invocation et il est arrêté après le Nième invocation
e) ing(demand Unmarshall g(demande) marshallin 1 2
t
t
t
t
t
communication
at) ing(result Unmarshall ) g(resultat marshallint
t
t
t
execution
communication
Figure 5-2: Un client fait une demande à un serveur
Serveur Client
t1 Demande
Chaque test à ses propres hypothèses concernant le modèle du temps en fonction et qui dépend :
Des paramètres d'entrée. Le temps de marshalling / unmarshalling des paramètres est une grande partie de temps d’appel.
Du temps d'exécution : qui dépend de la quantité de travail que le serveur a effectuée. De la valeur de retour : Le temps de marshalling / unmarshalling de résultat
de retour qui dépend de savoir si quelque chose est retourné et le type de données du résultat.
Du point de vue du client, un temps aller-retour est mesuré lorsque la demande est transmise à l'agent et un résultat est retourné.
Il est également intéressant de mesurer le temps sur le côté serveur, mais que les horloges du client et du serveur ne sont pas synchronisés, il est impossible de comparer la date de transmission une demande sur le côté client avec la date de réception de cette demande sur le côté de serveur.
D’après la figure précédente on déduit que :
Le principe de test se base sur le principe d’une communication client/serveur, suivant un algorithme de test de performance, afin de mesurer le comportement des différentes middleware par rapport aux données qu’il transmet.
Figure 5-3: Le temps a passé sur le côté client et serveur lors d’une requête
Début de l'horloge client
Client Serveur
temps temps
Début de l'horloge serveur
Le temps total sur serveur est T2 La Requête prend
du temps T1
Arrêt de l'horloge client
Arrêt de l'horloge serveur
e) ing(demand Unmarshall g(demande) marshallin
2
1
T
t
t
t
T
communication
at) ing(result Unmarshall ) g(resultat marshallint
t
t
communication
Toutes les tests sont réalisés en appel distant, c’est à dire que le client et le serveur sont installés dans deux machines différentes, qui nous permet de calculer le temps nécessaire à la lecture et à l’écriture de message, le temps de calculer comprend le temps de transport nécessaire aux messages pour se déplacer d’une machine à l ‘autre
Les tests sont exécutés plusieurs fois (100 fois) , et la moyenne de tous les temps est calculée et prenue en considération comme résultat final de test
Tous les tests ont été réalisés avec le même environnement et les mêmes données, afin d’obtenir des résultats comparables.
Plusieurs scénarios de test sont réalisés, pour exploiter les capacités d’appel des méthodes distantes, et extrait la performance et la réaction des différents middleware aux données qu’ils transmettent.
1. Transmission des entiers : le premier test effectué est une simple transmission, des séquences d’entiers sont envoyées au serveur, afin d’étudier la réaction des différents systèmes aux transmissions
2. Transmission des doubles : le deuxième test repose sur le même principe que le premier test, mais cette fois au lieu d’envoyées des entiers, on transmet des doubles.
3. Transmission des chaînes de caractères : le troisième test repose sur la transmission des chaînes de caractères au serveur, le test est effectue pour des tailles différentes de chaînes de caractères, ce qui nous permet d’étudier la réaction pour les grandes chaînes de caractères.
4. Transmission d’un tableau : le quatrirème test consiste à envoyer un tableau d’entiers, suivant le même principe que le test précédent, un tableau d’entiers est envoyé au serveur qui le renvoie au client, ce test permet d’étudier le comportement des différents systèmes face à des tableaux de différentes tailles.
5. L’addition : le dernier test est une simple addition de deux entiers envoyés au serveur qui renvoie au client la somme de ces deux entiers.
L’algorithme :
1- initialiser le client
2- initialiser la séquence des données à envoyer. 3- Pour i allant de 1 a nombre de tests faire
- T0 = prendre_heure() ; - chercher serveur
- envoyer une requête de données au serveur - attendre une réponse
- t1 = prendre_ heure() ;
- si la réponse est différente à la réponse souhaitable alors Incriminante le nombre d’erreurs.
- sauvegarder le temps de transmission fin pour
4- afficher la moyenne des temps.