Comparatif des performances .NET Remoting et WebServices  

Introduction

Les trois technologies mises en œuvre à travers différents scénarios sont :

1.      .NET Remoting avec un Channel (canal) TCP et un formateur binaire (Binary Formatter) de messages

2.      .NET Remoting avec IIS comme conteneur et http comme protocole sur un formateur binaire de messages

3.      Les WebServices pris en charge par ASP.NET dans IIS avec Soap (Simple Object Access Protocol)

J’ai aussi fait des comparaisons entre les WebServices ASP.NET et les composants .NET Remoting hébergés par IIS en utilisant un formateur de messages SOAP. Pour résumer brièvement : Ne le faites pas ! ASP.NET est dans tous les cas beaucoup plus rapide que son homologue du fait qu’il utilise un encodage des messages orienté document alors que .NET Remoting se base sur un encodage de type RPC (complexité supérieure). Cela ne m’a pas empêché de comparer TCP Remoting Binaire et les WebServices, technologies qui sont (ou seront) toutes deux à l’origine de la majeure partie des applications distribuées sous .NET. Là encore, pour résumer : TCP Remoting est le middleware le plus performant.

Les applications .NET Remoting utilisant le formateur binaire sont, dans la plupart des cas, plus rapides que leur équivalent ASP.NET (W/S). Cela ne veut surtout pas dire que les WebServices ne sont pas performants, mais leur utilisation doit se restreindre à l’échange de messages entre applications car ils s’avèrent inadaptés dans un contexte mono-application.

Voyons la méthodologie mise en œuvre dans les différents tests.

Méthodologie des tests 

Pour chaque technologies décrites précédemment, j’ai effectué les tests suivants :

·        Appel de méthode simple : 1000 appels de la méthode DoSomething() n’effectuant aucun traitement.

·        Petits objets : Appel d’une méthode retournant un objet simple. Après que cet objet [Serializable] soit retourné au client, il est re-expédié au serveur puis encore une fois renvoyé au client. Pour chaque test, l’objet est donc sérialisé et dé-sérialisé trois fois. L’objet en question possède 3 propriétés simples : String names, String FirstName, ArrayList orders. Le dernier étant initialisé à null. La méthode effectuant ce test est appelée 500 fois, soit 1500 sérialisations et dé-sérialisations d’objets.

·        Objets de taille moyenne : Même principe que précédemment, excepté que la collection ArrayList contient cette fois-ci 10 objets constitués des propriétés : DateTime time, Double amount, Double price, String article (~48 caractères). Cette méthode est appelée 300 fois, soit 900 sérialisations et dé-sérialisations.

·        Objets volumineux : Toujours la même démarche avec cette fois une collection de 25 objets du type Customer (Client), chacun contenant 25 orders (Factures) représentant 60 sérialisations et dé-sérialisations.

·        Petit DataSet : Un DataSet (jeu d’enregistrements passé par valeur) est généré sur le serveur, passé au client, puis renvoyé encore une fois au serveur (3 passages comme précédemment). Ce DataSet contient 5 colonnes de type String et 50 enregistrements ou ligne. Le test est reproduit 100 fois pour un total de 300 sérialisations/dé-sérialisations.

·        DataSet Moyen : DataSet contenant 250 lignes et 30 appels de méthodes, soit un total de 90 sérialisations/dé-sérialisations.

·        DataSet Volumineux : Le même DataSet contenant 500 lignes et 20 appels de méthodes, soit 60 sérialisation/dé-sérialisations.

Tous les programmes sont, soit des applications en mode console, soit des libraries DLL, mais dans tous les cas exécutées en dehors de Visual Studio .NET afin de retranscrire fidèlement un environnement de production.

Note : Dans tous les tests, une méthode « first call » est appelée afin d’initialiser le système car, en général, le premier appel est toujours long et ne reflète pas les performances moyennes.

Matériel/Logiciels

Ces tests ont été effectués sur deux machines. Le serveur est un Pentium 3 à 850 Mhz et 512 Mo de Ram tournant sous Win2000 SP2. Le client est un Sony Pentium 3 à 600Mhz avec 192 Mo de Ram en Win2000 SP2.

Au niveau réseau, ces deux machines sont interconnectées sur un réseau Ethernet 100Mbit dédié à ces tests.

Les résultats suivant ne sont valables que dans le cadre de la configuration listée ci-dessous. Les tests ont été effectué avec un seul client, ce qui ne permet pas de prendre en compte l’aspect montée en charge et multi-thread. Tous les scénarios ont été joués 6 fois afin d’en déduire des temps moyens. De plus, vous pouvez récupérer l’ensemble des métriques et résultats au format Excel dans le cas où vous souhaiteriez créer des graphiques personnalisés.

Résultats

Tous les graphiques montrent un temps moyen de référence (en %) par rapport au temps le plus long. Les barres les plus courtes sont donc les plus performantes.

Appel de méthode simple

Résumé : Pour un appel de méthode simple sans charge utile, les WebServices sont aussi rapides que TCP Remoting.

Petits objets 

Résumé : Le transfert de petits objets est le premier test qui a montré un léger avantage des WebServices. On tombe dans le cas où la sérialisation binaire IIS/Remoting est plus coûteuse que l’encodage en mode texte.

        Objets de taille moyenne  

 

Résumé : Les résultats concernant les traitements d’objets de taille moyenne mettent en avant un début de dégradation des performances des WebServices. Celles-ci dépendent directement de la taille des paramètres et IIS et TCP Remoting prennent 2 fois moins de temps à s’exécuter ! (c’est énorme)

        Objets volumineux

 

Résumé : Les résultats concernant les traitements d’objets de taille moyenne mettent en avant un début de dégradation des performances des WebServices. Celles-ci dépendent directement de la taille des paramètres. Dans cette configuration,  IIS et TCP Remoting prennent 2 fois moins de temps à s’exécuter par rapport aux WebServices !

        Petit DataSet

 

Résumé : Ce scénario, assez proche de celui sur le passage d’objets de taille moyenne, possède tout de même une particularité : TCP Remoting n’est pas beaucoup plus rapide que IIS avec un Formateur binaire. Cela fonctionne comme si la sérialisation utilisée par les deux technologies se basait sur un flux au format XML, même lorsqu’un Formateur binaire est utilisé…

 

        DataSet de taille moyenne

 

Résumé : Les résultats de ce scénario sont très intéressants. J’ai dû, à plusieurs reprises, renouveler les tests car je n’en croyais pas mes yeux. Les WebServices ASP.NET et Remoting sont équivalent avec un léger avantage pour Remoting. Cela démontre une chose : les WebServices avec .NET sont configurés pour utiliser au mieux les services du Framework dans le cas de transfert d’objets de taille moyenne.

 

        DataSet volumineux

Résumé : Le résultat était prévisible, TCP Remoting est largement plus rapide que les WebServices et IIS Remoting lorsqu’il s’agit de traiter des graphes d'objets complexes et volumineux. Dans tous les cas, évitez d’utiliser les WebServices pour transférer des grosses collections d’objets de type DataSet.

Conclusion

Qu’est-ce que tout cela signifie ? Et bien tout simplement que TCP Remoting est bien plus performant que toutes les autres technologies .NET, y compris les WebServices. Son utilisation doit être préférée aux autres méthodes lorsque cela est possible. Dans le cas où les firewall ne posent pas de problème et que la connexion TCP point à point est possible (avec un contexte mono-plateforme) pensez à TCP Remoting. Dans le cas où les firewalls posent problème et que client et serveur utilisent tout deux la même plate-forme (.NET), préférez IIS Remoting basé sur http. Ainsi, vous aurez la possibilité de profiter des services offerts par IIS concernant la sécurité (Authentification, SSL, HTTPS). Enfin, dans le cas où client et serveur ne partagent pas le même environnement, il faudra alors envisager de faire appel aux WebServices avec SOAP sur http.

Ce comparatif montre bien que toutes les technologies ont leur place dans ce monde, il ne tient qu’à vous de choisir la meilleure.

 

Auteur : Ingo Rammer

Traduit et adapté par Sami Jaber.

Télécharger les tests complets (sources, binaires et graphiques)

Les sources et binaires : AspNet vs Remoting .zip (138 ko)

Les résultats et graphiques : RemotingPerformance.xls (50 ko)

 

Remerciements

DotNetGuru remercie chaleureusement Ingo pour nous avoir permis de traduire son comparatif.
Nous vous engageons chaudement à faire l’acquisition de son ouvrage intitulé « Advanced .NET Remoting »

 

Ressources

http://www.dotnetremoting.cc (Site de Ingo Rammer)

http://www.dotnetguru.org/article.php?sid=7 (Articles sur .NET Remoting)

 

Copyright : DotNetGuru Ó 2002