2017-07-21 4 views
0

Je rencontre des temps de réponse très longs d'Exchange Online appelés via l'EWS Managed API 2.0 en C#. Je pense que je suis étranglé, mais je ne trouve rien qui me permette de le prouver dans le portail Admin de mon compte O365. J'ai vu dans certains résultats de recherche qu'en utilisant PowerShell vous pouvez voir des messages indiquant que des "micro retards" ont été appliqués, mais je suis coincé en C#/EWS, donc ma question est: est-ce que je peux regarder les réponses? à mes appels EWS qui peuvent identifier si ces retards micro ont été appliqués? BTW, les temps de réponse sont très proches du temps d'attente de 100 secondes, ce qui tue mon code.
Thx, Paul Tout moyen de détecter les micro-retards à l'aide du serveur Web intégré?

Répondre

0

100 secondes ins't un retard micro, micro-retards sont millisecondes (plafonnée à 500 ms) et sont plus destinés à retarder un grand nombre de demandes. (par exemple, si une application est susceptible de recevoir 100 requêtes séquentielles, un microdelay répartit le chargement de ces requêtes sur une période plus longue en punissant de plus en plus l'application, ce qui réduirait la charge de ressources sur le serveur). Une requête prenant 100 secondes à remplir est probablement davantage liée à la demande elle-même. Par exemple, la surutilisation des filtres de recherche ou de la recherche par surcomplexe, etc., qui a également un impact sur la limitation ou si vous utilisez le traitement par lot à chaque demande avec le lot, un délai de micro-application peut être appliqué. EWS ne renvoie pas de statistiques sur l'utilisation des gaz (la nouvelle API REST fournit un peu plus d'informations à cet égard). Ce dont vous avez besoin est l'accès aux journaux EWS qui a cette information. Chaque demande d'échange que l'API gérée par EWS fait a et le client demande d'aider à corréler la demande à l'entrée de journal plus en détail dans https://msdn.microsoft.com/en-us/library/office/dn720380(v=exchg.150).aspx

+0

Merci pour la réponse. Je pense que j'ai défini tous les en-têtes possibles, mais comme je parle à O365 à l'autre bout, je n'ai pas accès aux journaux EWS, sans appel de support, un chemin que j'ai commencé à explorer, jusqu'à présent sans trop de chance. BTW, l'appel qui semble obtenir les retards les plus constants est OpenStreamingConnections, qui n'a vraiment aucun volume de données de retour. Certains de mes FindAppointments prennent un peu de temps, mais je demande 48 heures d'appts à partir d'un seul calendrier, donc je ne pense pas que ce soit un problème de volume là non plus. J'apprécie la référence à la statistique des clients - peut-être que cela peut être utile. – pjneary

+0

Si ses OpenStreamingConnections le faites-vous pour un groupe d'abonnements? Si vous chargez les connexions à leur maximum (par exemple 200 par groupe), vous trouverez peut-être mieux de revenir sur ce nombre, ce qui peut améliorer les performances. Pour FindAppointments qui ne devrait pas vraiment être lent, (sauf si vous utilisez une charge en ligne pour obtenir plus de détails sur les participants à la réunion qui est un problème de performance commun avec le code EWS, par exemple en utilisant loadpropertiesforitems résoudrait cela). demandez par exemple les 100 derniers éléments, puis comparez l'heure avec les vues ou les filtres. –

+0

Encore une fois, j'apprécie la réponse. Donc - difficile à croire - mais je n'ai qu'une demi-douzaine de calendriers différents à regarder, et les groupes n'ont qu'un ou deux abonnements par connexion. Ma théorie actuelle est liée aux paramètres DNS sur la machine virtuelle Azure que je cours. Sur une autre machine virtuelle, il n'y a pas de retard sur le problème VM. La différence: une bonne machine virtuelle utilise le serveur DNS Azure DHCP; mauvaise VM a le DNS Google public (8.8.8.8). Les noms de domaine complets pour O365 sont résolus en adresses IP différentes. (J'espère que je suis sur la bonne voie!) – pjneary