2009-09-14 7 views
7

J'utilise l'espace de noms System.Management dans un .Net pour exécuter diverses requêtes WMI sur un serveur distant. Dans mes journaux, je peux voir que parfois les requêtes prennent 30 ou 40 secondes pour se terminer alors que d'autres fois les requêtes se terminent en moins d'une seconde. Lorsque je vois ces requêtes lentes, j'essaie de me connecter à la boîte en utilisant wbemtest, mais il se connecte toujours et exécute la requête rapidement.Pourquoi les requêtes WMI sont-elles si lentes parfois?

Des idées, des pointeurs, des suggestions?

J'ai remarqué en regardant System.Management.ManagementScope dans le réflecteur qu'il semble y avoir un pointeur IWbemServices. Il semble que ce soit une interface COM qui doit être appelée par Release (Marshal.ReleaseComObject()). Je ne suis pas sûr que cela soit lié ou non. Je me connecte à beaucoup de serveurs différents pendant la durée du processus.

Répondre

2

J'ai le même type d'application qui fait plusieurs requêtes WMI sur tous les différents types de périphériques et j'ai le même comportement. L'utilisation de wbemtest est parfois plus rapide mais pas nécessairement. Je trouve aussi que certaines requêtes sur la même machine se comportent différemment des autres requêtes sur la même machine simplement parce qu'une classe différente est une requête.

Il existe une propriété ReturnImmediately appartenant à la classe EnumerationOptions qui peut vous aider à obtenir les résultats plus rapidement si vous les obtenez dans un lot au lieu de les énumérer sur le réseau.

EnumerationOptions options = new EnumerationOptions(); 
options.ReturnImmediately = false; 

Vous pouvez essayer cela et voir si cela aide. Je sais que ce n'est pas ce que vous voulez entendre, mais mon opinion personnelle est que vous ne pouvez pas faire grand-chose. Vous devez écrire du code pour travailler autour du problème. La vraie réponse se trouve quelque part profondément enterré dans les bols de DCOM, le protocole WMI et le référentiel WMI.

+0

Malheureusement, je pense que vous avez raison. Je dois juste contourner le problème. Le paramètre ReturnImmediately a aidé un peu mais pas assez pour résoudre le problème. –

0

Le problème est-il spécifique à une boîte? J'ai déjà eu ce même problème avec un scénario à distance. Je l'ai réparé en reconstruisant la pile TCP/IP sur la boîte faisant l'appel à distance.

+0

Non, ce qui arrive à plusieurs des ordinateurs cibles (mais pas tous). Au moment où je vois les requêtes lentes dans les journaux et essayez d'interroger manuellement, le problème est résolu. –

+0

Qu'en est-il des ordinateurs sources (ceux qui effectuent les appels)? Le problème est-il spécifique à l'un d'entre eux? –

+0

Oui et Non :). Ce problème concerne plusieurs ordinateurs sources, mais tous les serveurs sur lesquels j'ai essayé n'ont pas ce problème. –

2

Vous pouvez essayer de définir le champ WITHIN pour voir s'il force la requête à se produire plus tôt. Pourriez-vous publier la requête que vous utilisez? Cela peut aider à déboguer d'autres problèmes

0

Regardez dans les indicateurs WBEM_FLAG_RETURN_IMMEDIATE & WBEM_FLAG_FORWARD_ONLY pour votre langue. Lorsque vous utilisez Scriptomatic (une petite interface graphique VBScript de MS pour passer des appels WMI), cette option est automatiquement ajoutée dans le cadre des options. Les 48 signifient WBEM_FLAG_RETURN_IMMEDIATE | WBEM_FLAG_FORWARD_ONLY. exemple VBScript:

objWMIService.ExecQuery ("Select * from Win32_NetworkConnection",,48) 

https://msdn.microsoft.com/en-us/library/aa390880(v=vs.85).aspx

Questions connexes