J'ai hérité du code qui fait de nombreux appels WMI à distance. Lorsque je suspends l'exécution à plusieurs reprises et que je regarde la pile d'appels, c'est presque toujours dans un appel ManagementScope.Connect(). Une nouvelle connexion semble être faite avec chaque requête WQL.Comment puis-je améliorer les performances WMI dans .NET?
Malgré quelques essais et erreurs, je n'ai pas encore trouvé de grandes victoires pour améliorer les performances des appels WMI.
J'ai essayé de mettre en cache les résultats précédents, de réutiliser les connexions et d'éviter le redoutable "select *". Ceux-ci ne m'ont pas donné les améliorations de performance que je voudrais. Je suis intéressé de comprendre l'impact de l'environnement sur les performances de WMI, mais le code doit fonctionner dans une grande variété d'environnements qui échappent probablement à mon contrôle.
Le cas échéant, quels sont les avantages et les inconvénients de l'accès WMI orienté performances dans .NET?
Effectuez-vous plusieurs appels sur la même machine ou sur plusieurs machines? Si ce dernier, avez-vous considéré multi-threading? – serialhobbyist
Pour l'instant c'est la même machine; le code est pour les installations à distance automatisées. Le code détermine d'abord quelles dépendances ont déjà été installées, interroge le système d'exploitation (en déterminant des choses comme l'architecture du processeur, le répertoire du système, le répertoire des fichiers du programme, la version du système d'exploitation, etc.); il le fait pour configurer l'installation, puis utilise WMI pour lancer et surveiller l'installation. Il y a eu une demande de fonctionnalité pour permettre à ceux-ci d'être mis en file d'attente et de courir parallèlement (par exemple 5 à la fois). Bonne suggestion. – devgeezer
Ah-hah. J'ai fait quelque chose de très similaire dans vbscript. Le mien était à la fois méchant et douloureux. Je vous souhaite bonne. – serialhobbyist