Définition des contrats de niveau de service pour les services WCF

Question

Je dois effectuer un test de performance/chargement d'un ensemble de services interdépendants. Ils utilisent tous net.tcp et la plupart utilisent des contrats duplex et des files d'attente internes. [classe de file d'attente POCO handrolled utilisant lock (syncRoot) {if (queue.Empty) Thread.Wait(); }]

est ici l'approche que je suis venu avec:

1. Identifier les services WCF pour être la performance testée
2. Identifier les compteurs de performance relavant pour chacun des services
3. Identifier la startpoint logique prendrait l'exécution via les services testés
4. Exécuter automatiquement des tests unitaires à l'aide de VS.Net pour chacun des services
5. Écrire des tests fonctionnels spécifiques (Pour examen Je peux prendre un cas d'utilisation - "Passer une commande" - et écrire des tests qui effectuent tous les appels aux services concernés et excercent généralement toutes les fonctionnalités nécessaires.)
6. Utilisez les fichiers de trace de # 5 pour générer Tests unitaires [utilisant le test de charge WCF de CodePlex] (Cela me semble en quelque sorte un outil idéal pour recréer des erreurs d'utilisateur en production/champ dans un environnement de débogage. Disclaimer: Non utilisé l'outil. Impressions de la lecture du projet desc)
7. Les tests ci-dessus pourrait être modifié pour faire des appels avec des données d'entrée généré automatiquement
8. Introduire des variations à l'entrée si différents chemins de code sont excercised
9. données du journal de compteurs de performance
10. Analyser et d'identifier les goulots d'étranglement

Questions:

1. y at-il une meilleure approche?
2. Dans le cas de services utilisant des files d'attente internes, la mesure des performances à l'aide de compteurs de performances STD constitue un problème. J'ai peut-être besoin de compteurs personnalisés?
3. Si la valeur 1 est vraie, existe-t-il un moyen d'introduire des compteurs clients sans modifier le code des services testés?
4. Dois-je m'intéresser aux résultats de mes tests fonctionnels?
5. Existe-t-il un moyen de mettre en œuvre [non intrusif] SLA pour les services WCF? (Je pense que si j'ai suffisamment de données de mes compteurs comme les demandes traitées, les exceptions, le temps de réponse etc., je devrais pouvoir valider mon SLA - servir 200.000 demandes en 5 minutes avec un temps de réponse de 2 secondes pour chaque requête Ma question est peut-être de savoir si je peux juste spécifier mon SLA et un produit/outil pourrait faire toute la plomberie derrière la scène et obtenir une réponse tabulée? Je sais ... Je sais ... Je rêvais de jour :))
6. À côté: Quelle est la meilleure méthode pour mettre en file d'attente des demandes en interne dans un service WCF?

Answer 1

Wow ... le titre était définitivement la pointe de l'iceberg! J'espère que je ne suis pas loin de la base ici sur mes réponses! :)

1. tests de performance

   des services WCF peut se faire de différentes façons: en utilisant des outils de test tels que le test Microsoft Team, Borland Silk Performer, Mercury LoadRunner, ou quelque chose comme LoadGen ou un harnais de test personnalisé.Ma préférence est d'essayer d'utiliser l'approche que vous avez utilisée pour créer une sorte de test unitaire fonctionnel, puis d'alimenter des données dans ce test, tout en utilisant l'outil de test pour générer plusieurs instances simultanées de ce test (utilisateurs virtuels) . L'outillage de la plupart des outils de test commerciaux facilite vraiment ce type de test, il est donc difficile de s'y tromper. Le plus grand défi provient généralement de la maintenance des cas de test et des données de test pour prendre en charge le test de l'application.

2. WCF ne possède aucun compteur intégré lié aux performances. C'est en fait une tache aveugle. Bien sûr, vous pouvez voir combien de connexions sont effectuées sur le serveur, mais ce sont des informations grossières et vous voulez probablement savoir quels services traitent ces demandes. La rumeur veut que le «Dublin» de Microsoft, dans le cadre de la fourniture d'un environnement d'hébergement riche pour WCF/WF, comprendra des compteurs de performance de surface pour le service hébergé. Nous devrons attendre et voir ce qui se passe réellement. Si j'avais besoin d'instrumenter un service WCF sans affecter le codebase existant, j'examinerais combien de kilomètres je pourrais tirer d'un comportement WCF que je pourrais appliquer au service. Ce comportement personnalisé pourrait faire surface les compteurs de performance que vous pourriez vouloir.

3. Oui. Je m'intéresserais aux résultats (c'est-à-dire aux performances?) D'un test fonctionnel. La mise en garde est qu'il y a probablement un démarrage (JIT) qui peut être ignoré. Je chercherais probablement à profiler l'exécution d'un test fonctionnel pour obtenir des métriques d'exécution - mais je n'activerais pas le profilage de code pendant une exécution de performance.

4. Pour les accords SLA, les comportements personnalisés peuvent être la solution. Vous pouvez consigner des mesures opérationnelles dans une base de données, puis les signaler. Des produits commerciaux comme Amberpoint et SOA Software apporteront également leur soutien (y compris les compteurs de performance).

5. Mise en file d'attente de demandes à un service wcf? Je pense immédiatement à la liaison net.msmq, surtout si vous cherchez à rendre la requête durable.