Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

AppFabric – Faut il l’utiliser pour écrire une couche de service ?

Avec l’arrivé de AppFabric, il est désormais simple d’héberger des workflow Worflow Foundation dans IIS.

Afin de communiquer avec l’extérieur, un Workflow peut utiliser les composants ReceiveRequest et SendRequest, ces composants utilisent WCF pour dialoguer. Il est donc tentant d’écrire sa couche de service en utilisant AppFabric.

Je me suis intéressé à cette question.

D’un point de vue performance, j’ai réalisé un service WCF classique et un service WCF utilisant WF. Ces 2 services réalisent la même chose. Ils ne font rien d’intéressant, je souhaitais juste connaitre le surcout lié à WF.
Vous trouverez ci-dessous le code utilisé.

Service WCF classique :

image

Service WF :

image

Et voici le code utilisé pour mesurer les performances :

image

Les tests sont multithreadés pour simuler une forte charge.

J’ai exécuté le code sur ma machine (8Go de ram, 8 cœurs) en utilisant IIS7.5 (Windows 7). Les 2 tests se sont effectués à la suite, dans les mêmes conditions.

Avec la configuration par défaut, j’obtiens les résultats suivant :

  • Service WCF classique : 3.5 secondes
  • Service WF classique : 6.3 secondes

Sans surprise, la solution utilisant WF est plus lente. Par contre, le delta est conséquent : +80%. J’ai alors vérifié la configuration du service au niveau IIS, et désactivé le Monitoring.

image

Après avoir refait un test, les résultats sont les suivant :

  • Service WCF classique : 3.5 secondes
  • Service WF classique : 4.5 secondes

La différence de performance est alors réduite, la surcouche WF ne coute plus que 30%.

    Nous avons vu que d’un point de vue technique, l’écart de performance est faible. Si le service n’est pas critique en terme de performance, ce choix est tout à fait envisageable.

    D’un point de vue fonctionnelle, il faut se demander si l’on a vraiment besoin de Workflow Foundation ou si les services WCF classique suffisent. Voici les questions que l’on peut se poser ?

    • Allez-vous utiliser les composants de Workflow Foundation ? ou créer une activité personnalisée qui contiendra tout votre code ?
    • Vos workflow ont-ils une vie ? Accèderez-vous plusieurs fois à vos Workflow ?
    • Allez-vous persister vos Workflows ?
    • Allez-vous surveiller vos Workflows ? (monitoring)

    Si vous répondez non à toutes ces questions, le choix de Workflow Foundation avec AppFabric n’est peut-être pas nécessaire pour vos besoins, sinon, ce choix est envisageable.

    Et vous ? Qu’en pensez-vous ? Dans quelle contexte avez-vous utilisé AppFabric ?

    Posted: lundi 4 avril 2011 12:20 par cyril
    Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

    Commentaires

    JeremyJeanson a dit :

    Dans ton exemple, il est fort probable que la différence de performances soit à imputer au WorkflowServiceHost conjoint à l'effet de la méthode CacheMetaData() sur de petit workflows et sans cache, ça a un effet dévastateur :(.

    Mais je suis parfaitement d'accord avec tes propos.

    Il faut se poser c'est questions avant même de commencer à vouloir toucher WF.

    Perso, j'ajouterai à ta liste le fait de ne pas avoir besoin :

    - D'exposer des service avec un autre binding qu'HTTP? (WFS est très très fort sur MSMQ, TCP et canaux nommés!)

    - D'utiliser des behavior propres à WF?

    Après on a tout de même les spécificités de l'AppFabric que l'on ne peut pas toujours facilement reproduire:

    - L'autostart de l'AppFabric? (qui donne l'avantage à WFS car les CacheMatadata pevent être chargés par le WorkflowSerciceHost, ce que WCF ne sait pas faire seul)

    - L'arrêt d'une instance d'un service à la main sans casser un apppool?

    - La perte d'un serveur alors qu'une opération était en cours?

    - Le cache distribué sur le cluster AppFabric?

    Pour moi l'AppFabric, c'est surtout une solution de haute disponibilité. En plus elle rend plus simple le travail pour les développeurs qui peuvent avoir du mal avec certaines notions de WCF.

    Perso, je l'ai utilisé autant pour de service classiques en WCF qu'en WFS pour effectuer des opération "orientées infrastructure sur un AD" (création de comptes, répertoires, recherche d'informations sur le réseau... etc...)

    Mais quand je dois juste faire un service du style "Provider d'authentification", je ne réinvente pas la roue. Il y a des services pour ça, et ils marchaient très bien avant l'AppFabric ;)

    L'AppFabric dans ces cas là, c'est comme un site en MVC pour afficher 3 pages statiques... pas besoin d'un razor pour écrire du HTML ;)

    # avril 4, 2011 17:05
    Les commentaires anonymes sont désactivés

    Les 10 derniers blogs postés

    - Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

    - Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

    - Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

    - Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

    - Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

    - Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

    - Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

    - Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

    - SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01

    - SharePoint Online: Script PowerShell pour supprimer une colonne dans tous les sites d’une collection par Blog Technique de Romelard Fabrice le 11-27-2018, 18:01