Nous avons un service Web avec les points de terminaison WSE 3.0 et les nouveaux points d'extrémité WCF sur .NET Framework 4.5.
wcf utilise Le problème est que Les nouvelles reliures J'ai lu beaucoup sur l'activation du traçage de la WCF. Mais lorsque je le permette à la production, je reçois une bonne information et je ne sais pas vraiment comment lire par ex. La chronologie de Microsoft Trace Viewer. J'apprécierais toute aide Notes:
Le problème existe dans la production; sur les serveurs de test, tout va
amende. Au début, nous avons soupçonné que l'équilibreur de charge pourrait être un facteur,
mais la désactivation de l'équilibreur de charge ne modifie pas les performances du tout
La lenteur pourrait être dû Notre couche d'application / domaine de domaine bien sûr.
Peut-être que du bassin de fil / de connexion bloque et les messages obtiennent
en file d'attente à cause de cela.
Dans ce cas, quelqu'un a une idée pourquoi le comportement est tellement
différent de WSE (qui fonctionne sur le même pool d'applications)? A fait
Tailles de la file d'attente / Traitement simultané Configurations par défaut Changement
spectaculaire entre WSE3.0 et WCF?
Y a-t-il un moyen de savoir quand cela se passe-t-il? Par exemple. Quelques Voici une version anonymisée de notre service web.config: BasichttpLinding .
PERFMON Compteurs à regarder ? Dans perfmon Je viens de vous perdre en choisissant entre l'énorme quantité de compteurs de performance disponibles
mise à jour
4 Réponses :
Désolé de répondre en réponse, je n'ai pas assez de réputation pour commentaires.
Quelles informations spécifiques (traces) vous souhaitez voir? Si vous avez des difficultés à la mise en place de la traçabilité, je vous recommanderais d'utiliser l'outil nommé SVCConfigeditor.exe. Vous pouvez ouvrir un fichier App.config de votre service WCF et sous "Diagnostics", vous pouvez activer la traçage. Après cela, vous pouvez choisir si vous souhaitez tracer des informations particulières - appelée "Niveau de trace" (plus d'infromation sur les niveaux spécifiques - Configuration de la traçage ). Voir Capture d'écran de l'outil:
Après avoir suivi les informations requises, vous pouvez ouvrir le journal de la visionneuse Microsoft Trace-Viewer, vous pouvez afficher la durée de chaque acitulation: Par exemple, considérez celui-ci (désolé - certaines étiquettes sont en langue tchèque):
Désolé, la photo était illisible, voici un lien vers Bigger One: trace Visionneuse
À gauche, vous pouvez sélectionner une activité particulière - si vous étirez le panneau, vous pouvez même voir l'heure de début et de fin. En outre, vous voyez la durée totale de cette activité. Après l'avoir sélectionné, dans le panneau supérieur gauche, vous pouvez voir tous les appels, qui appartiennent à cette activité et que vous pouvez également voir, quel appel a pris le plus de temps pour résoudre (dans la colonne "Time").
Merci d'une réponse, y a-t-il une façon de suivre des messages uniquement d'un ordinateur client? Je veux dire ajouter un traçage sur le serveur, mais je ne suis intéressé que par un ordinateur client que je recherche un problème maintenant
HMMM, je suppose que vous devriez commencer à tracer côté client, plutôt que sur le côté serveur. Simplement désactiver (supprimer) Traçage de service app.config et configurez-le dans l'app.config. Cette discussion suggère que cela peut être fait: social.msdn.microsoft.com/forums/vstudio/en-us/...
Merci d'aviser. Des journaux côté client, je ne vois rien d'intéressant J'exécute une méthode 100 fois et peut voir que parfois c'est exécuté dans une seconde et parfois ~ 10 secondes, c'est tout ce que je vois, mais j'aimerais avoir plus d'informations du côté serveur de quelle est la différence entre ces 2 appels
Well Trace Viewer ne vous dira-t-il pas, pourquoi une méthode spécifique a duré plus longtemps que la précédente, c'est vrai.Si vous avez besoin d'inspection détaillée de chaque méthode, vous pouvez utiliser l'outil de performance et de diagnostic (en VS, sous tabal Analyze) et exécutez un test spécifique. Je n'ai pas beaucoup fait avec cet outil cependant, donc je ne connais donc pas les détails - mais par exemple si j'exécute un test de consommation de la CPU, puis créez un rapport détaillé, je peux voir quelle étape de la méthode a pris un certain temps:
Malheureusement, je n'ai pas de studio Visual sur le serveur car il s'agit de toutes les productions, de même que vous rechercherez de toute façon grâce de l'aide
Oh ok.vous êtes les bienvenus ... Peut-être que quelqu'un d'autre postera une réponse avec un bon outil de diagnostic qui sera capable de vous aider :).
Utiliser le diagnostic de WCF est génial, mais aussi loin que je sache, vous ne pourrez pas obtenir de diagnostics similaires à partir du service Web afin que vous n'ayez rien à comparer. Cependant, les diagnostics que vous préparez dans votre réponse vous donneront une indication d'un temps relatif dépensé dans chaque phase de l'appel de service.
Je proposerai une alternative qui devrait être très simple car vous utilisez http / text dans les deux cas. Attrapez simplement les deux réponses à l'aide de Fiddler ou de votre outil de proxy préféré et comparez. Et de manière critique - assurez-vous de regarder l'en-tête HTTP, pas seulement du corps. Fiddler vous dira le temps de retour et la taille de la réponse, qui devrait suffire.
Qu'est-ce que cela pourrait être? Les choses évidentes:
[System.ServiceModel.ServiceBehavior (ConcurrencyMode = System.ServiceModel.ConCurrencyMode.Multiple)]
Vous êtes correct en ce qu'il existe de nombreux compteurs de performance pour WCF. Ils sont regroupés par service, point final et opération. Vous voulez probablement les compteurs de service, car ils ont plus d'informations. Cochez la catégorie Servicemodelservice 4.0 et regardez
- appels (évidemment)
- appels par seconde
- instances
- instances créées par seconde
Nous utilisons uniquement la sécurité du niveau de transport. Les messages ne sont pas cryptés.
ConcurrencyMode est célibataire pour le moment, nous examinons nos options pour changer cela maintenant.
ConcurrencyMode = System.Servicemodel.ConCurrencyModeMode.Multiple a essayé de cette façon et n'a fait aucune différence
Votre fichier de configuration de service WCF n'apparaît pas avoir des valeurs d'étranglement explicitement définies. Vous voudrez peut-être utiliser Performance Monitor pour suivre les ressources de la WCF et / ou ajuster les valeurs par défaut pour vous assurer que vous n'allez pas frapper la limite des gaz par défaut.
Logement du service ( https://msdn.microsoft.com/en-us/library/ee377061%28v=bts.70%29.aspx ServiceThrottling ) vous permet de même Sur la charge de vos serveurs Backend WCF et pour appliquer l'allocation des ressources. Le comportement des services de service des services de WCF Backend est configuré en modifiant les valeurs du maxconcurrentcalls , maxconcurrentessions et MaxConCurrentInstances paramètres dans le fichier de configuration pour le service de la WCF .
Depuis que le problème est apparu, nous avons essayé de jouer avec ces paramètres (ServiceThrottling) et essayé même d'énormes numéros tels que MaxConCurrentCalls = "100000" mais cela n'a fait aucune différence
Pouvez-vous fournir vos paramètres de propriété InstanceContextMode et ConcurrencyMode?
InstanceContextMode = InstanceContextMode.PerCall, ConcurrencyMode = ConcurrencyMode.Single
L'article suivant décrit certaines considérations utiles, 1. Assurez-vous que le service a suffisamment de threads IO dans le threadpool (SetMintHreads) 2. S'assurer que le constructeur de classe de service est efficace (c.-à-d. Aucune initialisation coûteuse) THEBURNINGONK.COM/2010/05/...
@Seymore Surtout avec ce dernier commentaire, votre réponse a été un trésor de la connaissance. Je laisserai au PO d'accepter une réponse (un peu de temps à l'avenir). Mais à ce stade, je souhaite adresser la prime à vous. Merci de partager votre savoir
Je suggérerais de déboguer cela de la manière suivante:
Supprimez temporairement toutes les logiques d'authentification et de sécurité des deux services et voyez si le problème reste
désactiver temporairement toute logique commerciale et éventuellement simplifier le schéma à une seule variable
Lorsque vous dites que la performance est plus lente, voulez-vous dire une seule performance utilisateur ou un test de charge? Lorsque vous vérifiez un seul utilisateur, assurez-vous que le serveur est chaud?
Si vous avez durée la durée d'exécution de votre logique (par exemple de début à la fin de la mise en œuvre de votre méthode de serveur) - est-ce la même chose?
N'oubliez pas d'annuler tout journalisation / traçage tandis que Benchmarking
Vous pouvez essayer de revenir wcf à
1 - Ceci n'est pas possible dans la mesure où le serveur et les clients sont déjà en production 2 - non pas possible pour l'instant 3 - reproduit de manière stable pour toute application client 4 - 90% sûr que le temps est le même 5 - vrai 6 - également difficile à essayer En raison de tout cela est en production mais nous devons considérer cela
Microsoft affirme qu'il est 4 fois plus rapide en raison de l'utilisation de xmldocument vs xmlreader: msdn.microsoft.com/en-us/Library/... . Il semble que vous faites quelque chose comme le filtrage de votre reliure qui est mauvais pour vos performances de la WCF. Pouvez-vous publier vos liaisons et quels attributs avez-vous sur vos méthodes de service?
@Peer, voici les reliures (anonyme): Pastebin.com/vkhxeqbq
Vous avez personnalisé notre chiffroduct.business.Authentication.CustomusernamétokelManage R et OurProduct.Service.Validation.customusernamePasswordvalidato r classes pour la sécurité. Avez-vous testé la différence de performance sans eux pour être sûr de la mise en œuvre de Notre OurProduct.Service.Validation.customusernamePasswordvalidato R n'est pas le problème.
Il est difficile de tester cela car le problème n'est reproduit que dans l'environnement de production (non reproduit pour tester ou dev. Ordinateurs) et ce fait me fait également sentir que ces paramètres ne font aucune différence ici sinon la question serait reproductible partout.