2009-08-04 8 views
3

Nous avons une application .NET 3.5 qui appelle un webservice sur le serveur. Dans presque chaque installation de cette application, l'ensemble du processus demande/réponse prend environ une demi-seconde.Qu'est-ce qui peut causer un retard de deux minutes dans l'appel d'un service Web?

Dans une installation particulière, ces demandes prennent mystérieusement presque exactement 85 secondes (en une demi-seconde). Mon premier réflexe était que le client webservice reconstruisait l'assembly de sérialisation XML à chaque appel, mais même envoyer directement un fichier xml codé en dur prenait presque exactement le même temps. Regarder le trafic réseau semble indiquer que la partie réelle des données d'envoi de la transaction se passe en moins d'une seconde. Donc, le problème est du côté du client.

Y a-t-il une sorte de retard des autorisations qui pourrait causer ce problème? L'application est un wrapper de base autour des requêtes webservice - tapez quelques paramètres, envoyez une requête au webservice et obtenez une réponse. Nous avons commencé avec le code client généré par l'outil wsdl.exe, mais nous avons également essayé d'utiliser directement HttpWebRequest lorsque nous avons rencontré les problèmes. De suivre les journaux et les traces du réseau, le flux semble être:

T 0:00 - user initiates request 
T 1:24 - the application sends request to server 
T 1:25 - the client receives the response and displays to the user. 
+0

À ce stade, il faut que ce soit l'authentification, ce qui est l'ensemble de la sécurité sur votre service web? –

+0

Il fonctionne sur http simple sans authentification sur un VPN. –

Répondre

1

Si les données sont envoyées en moins d'une seconde, mais le temps de réponse totale est de 85 secondes, pourquoi vous vous sentez le problème est sur le client côté? Est-ce que cela prend 85 secondes pour recevoir la réponse du serveur?

Généralement, si vous voyez ce type de délai très cohérent (d'une demi-seconde), recherchez une sorte de délai d'expiration dans votre traitement. Cela ressemble beaucoup à un délai d'attente réseau. Y a-t-il une ressource réseau à laquelle le serveur pourrait essayer d'accéder? L'authentification est une telle ressource réseau. Un partage de fichiers, un appel http ou ftp externe peuvent également être candidats.

Pouvez-vous décrire votre application plus en détail?

1

Cela ressemble à un problème de délai d'attente. Une pensée: quel type de proxy est configuré? La machine essaie-t-elle de détecter un proxy HTTP avant de faire la demande? Je pense qu'il est temps d'utiliser un moniteur réseau pour voir ce qui se passe.

0

Si le service est également .NET, vous pouvez identifier la source du problème à l'aide du suivi. Vous pouvez ajouter des traces à votre web.config comme suit:

<system.diagnostics> 
     <sources> 
      <source name="System.ServiceModel" 
        switchValue="Information, ActivityTracing" 
        propagateActivity="true"> 
       <listeners> 
        <add name="traceListener" 
         type="System.Diagnostics.TextWriterTraceListener" 
         initializeData="c:\temp\Traces.txt" /> 
       </listeners> 
      </source> 
     </sources> 
    </system.diagnostics> 

Cela retracera toute activité de « System.ServiceModel » qui est webservices à 3,5

0

Utilisez un programme comme Wireshark pour renifler le réseau lorsque vous faites la demande. D'abord chez le client et si vous êtes encore dans l'obscurité au serveur. (les deux en même temps donne encore plus de perspicacité).

De cette façon, vous pouvez exclure, retransmissions tcp-ip, les problèmes d'authentification, bizarreries proxy, etc etc

3

Merci pour toutes vos suggestions. Le problème était provoqué par l'auto-détection du proxy. Fondamentalement, si Internet Explorer est configuré pour détecter automatiquement les proxies, alors HttpWebRequest le fera aussi, seulement il détectera automatiquement chaque fois que vous créez une nouvelle requête Web au lieu de mettre en cache quoi que ce soit d'une manière utile.

Finalement, je trouve cet article KB: http://support.microsoft.com/kb/968699

La solution était tout simplement d'ajouter ceci au fichier app.config:

<configuration> 
    <system.net> 
     <defaultProxy > 
      <!-- Disable Autoproxy--> 
      <proxy autoDetect="false"/> 
     </defaultProxy> 
    </system.net> 
</configuration> 
Questions connexes