Macro qui ping des serveurs lente

**patricktoulon** · 19/11/2016, 18h10

bouhhh.... je m'en fou il me viendrait jamais a l'idée de faire ca
comme je l'ai dis plus haut pratiquement tout ce qui se fait dans un module vba peut se faire en VBS
alors pourquoi faire simple quand on peut faire compliqué hein!!...

nanananereheu....

**joe.levrai** · 19/11/2016, 19h01

Il ne te viendrait jamais à l'idée de lancer une macro excel via un vbs ?

Ma foi, si tu n'en a pas les besoins, ça se défend.

quand tu dois faire tourner des tâches sur des machines virtuelles, c'est extrêmement pratique.
tu ferais comment dans ce contexte, avec une autre méthode que le vbs qui effectue le .Run ?

tout est question de besoin, comme toujours

**patricktoulon** · 19/11/2016, 19h54

mais non!...

avec la librairie shredule on peut programmer des taches tant qu'on veut en vba ou vbs

et je ne vois pas pourquoi je ferais un vbs pour lancer un macro vba

le code je le met directement dans le vbs ma foi

**joe.levrai** · 19/11/2016, 20h13

Ma question n'est absolument pas un piège, bien au contraire.
Je n'ai jamais dis que ce dont je parle est la meilleure solution possible, et je ne voudrais surtout pas fermer la porte à une idée beaucoup plus lumineuse que ce que j'utilise.

Oui, la tâche planifiée crée à la volée, je sais bien que c'est possible (y compris sa destruction après exécution).
Mais .... il faut bien à un moment où à un autre que tu ai une autre "tâche" qui puisse lancer le vbs chargé de créer les tâches annexes ?

Par phénomène de cascade, on peut aboutir au syndrome des poupées russes, et je ne suis pas certain que ça devient très pratique.
Ton postulat de la création de tâche planifiée à la volée, c'est bien quand l'utilisateur exécute lui-même la procédure qui ira créer les tâches. Mais dans le cadre d'une automatisation d'un "automatisme de tâches planifiées" (surtout quand la tâche aura vocation à être période et récurrente) ... je ne suis pas certain que ce soit la panacée ?

le code je le met directement dans le vbs ma foi

Donc tu écris les lignes de ta macro VBA dans le vbs est tu le lances

Ok, donc :

- si tu dois manipuler des classeurs, il faudra bien que ton vbs l'ouvre tôt ou tard ?
- si la procédure à lancer est également une procédure que peuvent utiliser des "utilisateurs"

==> tu serais obligé d'appeler le VBS pour importer ou lancer la macro VBA ? Ce qui irait à l'encontre de toute logique dans ce exemple précis ?

**patricktoulon** · 19/11/2016, 20h36

Oui, la tâche planifiée crée à la volée, je sais bien que c'est possible (y compris sa destruction après exécution).
Mais .... il faut bien à un moment où à un autre que tu ai une autre "tâche" qui puisse lancer le vbs chargé de créer les tâches annexes ?

la librairie Schedule peut être manipuler en vbs aussi si tu cherche bien je l'ai prouver pour le pseudo sephyto
un peu de recherche ca fait pas de mal

on crée le travail dans un vbs on lance shredule en vba 1 fois !!!!!!!!!!!!

dans le vbs créé on fait la même chose (on relance la tache a heure différente )

résultat c'est toujours le vbs qui fait le boulot et ouvre excella que pour y "COLLER LES DONNEES"

1 vba écrire le code vbs et création fichier vbs avec le shedule aussi

2 on a erit le code du Schedule on le fait dans vba :on le lance

le vbs a chaque fois qu'il sera lancer créera un nouveau Schedule

point barre

après dans une session (Windows tout version confondu) simulée dans une partition je crois Scripting runtime est désamorcé alors la question ne se pose même pas un peu comme en mode sans échec
a méditer

nanananere heu....!!!
allez on est dans un bon jour un indice(valable en vba!!! et!!! en vbs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Sub test()
'********************************************************
' Créer l'objet TaskService.
Set service = CreateObject("Schedule.Service")

et la marmotte elle met .........

**joe.levrai** · 19/11/2016, 20h55

On ne se comprend pas là, et le débat en devient non productif
Nous n'avons ni tort ni raison, on parle simplement d'un environnement "besoin/tâche" différent, et c'est ça qui dénature tout l'intérêt de notre débat.
J'avais suivi attentivement cette discussion de Sebphyto, également les discussion avec vos abeilles et tout le tralala ... et j'avais énormément aimé les résultantes proposées.
Oui je fais de la recherche sur le forum, oh que oui, mille fois même

Je préfère fermer le chapitre si tu le veux bien, et je vais rester sur ma position qui ne remet pas en question ce que tu proposes bien sûr :

pour des procédures VBA amenées à être utilisées manuellement et à automatiser sur des lancements programmées sur une VM ... il est préférable de laisser le VBA dans les classeurs, et de monter les vbs (lancés dans des tâches planifiées) pour ouvrir les classeurs et .Run les macros.

Créer dynamiquement des tâches par un "master vbs" qui va créer un enfant vbs avec du code VBA, c'est pratique pour du one shoot ou des lancements a-périodiques.
Mais pour des tâches, qui de toute façon sont lancées automatiquement chaque jour à la même heure, les créer à la volée ne sert strictement à rien car si tu détruit tout les jours une tâche pour la recréer le lendemain ... quel intérêt.

C'est comme utiliser un classeur "modèle" qui chaque jour irait créer un nouveau classeur en y important les modules contenant les procédures, pour y faire "un traitement" ... et finalement détruire le nouveau classeur derrière.

Tu vois ce que je veux dire ?

**patricktoulon** · 19/11/2016, 21h09

re
oui je vois tes bien ce que tu veux dire
mais je mesui fourvoyé en te répondant
en fait avec la librairie on peut programmer la tache only comme perpétuelle ,a horaire précise, etc...comme avec schtasck

donc créé ton VBS
tu créé ta tache (multiple, périodique, etc.....selon ton choix ) par vba (1fois!!!)
et tu la lance, elle s'enregistre
et on va boire une bonne bière au pub on reviens le job est fait

je t'ai répondu en regardant les module pour sebphyto j'en ai encore des brives (il m'a tellement énervé celui la !!)y comprends rastafarien ca chanson il chante en anglais(met de l'huile)

et c'est vrai que depuis j'ai approfondi mes recherche sur cette librairie que je saurais trop te conseiller de l'explorer vu que tu aime ce genre de trucs

**jurassic pork** · 20/11/2016, 08h52

hello,

Envoyé par Marc-L

Le VBScript n'est effectivement pas toujours plus rapide que le VBA mais dans le cas d'un besoin externe au VBA
d'une multitude d'appels en séquentiel alors le multi-taches Windows via VBScript est bien plus rapide …

hello,
Bon, j'ai essayé le code à Patrick et il fonctionne très bien et il est très rapide. Les seuls petits bémols (très mineurs) que j'ai pu constatés :
1 - Il y a autant de processus qui tournent que d' adresses à tester.
2 - Il y a un pic d'utilisation CPU pendant la création des processus mais cela ne dure vraiment pas très longtemps.
3 - Si vous vous amusez à écrire dans des cellules de votre feuille Excel pendant la collecte, il y a plantage de quelques processus.
4 - Un fichier est créé pendant le test.

Partant du principe du code à Patrick, je me suis dit pourquoi ne pas essayer de faire la même chose dans un assemblage dotnet. En effet grâce à l'option Prise en charge de la programmabilité .NET de l'installeur Office :
Nom : Office-OptionsExcel.png
Affichages : 368
Taille : 8,1 Ko

Nom : Office-OptionsExcel.png
Affichages : 368
Taille : 8,1 Ko

on peut facilement manipuler des objets Excel en dotnet.
J'ai donc créé un assemblage dotnet à interface COM en C# (JpDotnet) avec une classe (Pingueur) qui contient une méthode MultiPingThread . Cette Méthode possède deux paramètres : le nom du classeur et la plage de cellules où se trouve les adresses à tester. Le principe de la méthode :
On crée des threads (un par adresse à tester). Dans ces threads on fait un ping de l'adresse et on écrit dans la feuille excel de départ, les résultats dans les colonnes suivant la colonne des adresses.
A titre indicatif, voilà à quoi ressemble le code C# de la méthode MultiPingThread :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 public void MultiPingThread(string NomClasseur,string RangeIP)
       {
       	try
       	{
       		xlApp = (Microsoft.Office.Interop.Excel.Application)Marshal.GetActiveObject("Excel.Application");
       		xlBook = xlApp.Workbooks[NomClasseur];
       		xlSheet = (Worksheet)xlBook.Worksheets[1]; // on utilise la première feuille
       		List<Thread> threads = new List<Thread>();
       		foreach (Range c in xlSheet.Range[RangeIP].Cells)
       		{
       			string loopIp =  c.Value.ToString();
       			Thread thread = new Thread(() =>
       			                           {
       			                           	try
       			                           	{
       			                           		PingReply reply = null;
       			                           		using (Ping ping = new Ping())
       			                           		{
       			                           			reply = ping.Send(loopIp);
       			                           		}
       			                           		c.Offset[0 ,1].Value = reply.Status.ToString();
       			                           		c.Offset[0 ,2].Value = reply.RoundtripTime.ToString();
       			                           	}
       			                           	catch (Exception ex)
       			                           	{
       			                           		MessageBox.Show("Exception : " + ex.Message);
       			                           	}
       			                           });
       			threads.Add(thread);
       			thread.Start();
       		}      		
       	}
       	catch (Exception ex)
       	{
       		MessageBox.Show("Exception : " + ex.Message);
       	}
       }

Les try - catch permettent de gérer les exceptions. Si on ne les mets pas il y a risque de crash Excel pendant l'utilisation de l'assemblage car une exception non géré fait arrêter l'exécution du code dotnet.
Voici le code VBA d'appel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Sub Test_JPMultiping()
Dim MyJpDotnet As JpDotnet.Pingueur
Set MyJpDotnet = New JpDotnet.Pingueur
Debug.Print "Test Pingueur"
Range("B12:C29") = ""
MyJpDotnet.MultiPingThread ThisWorkbook.Name, "A12:A29"
End Sub

et voici le résultat:

Nom : excelMultiPing.gif
Affichages : 363
Taille : 32,8 Ko

Le temps d'obtention des résultats est similaire à celui du code à Patrick. Ce qui est amusant, c'est qu'il y un timeout sur microsoft.com. Effectivement Microsoft ne répond pas au ping.
Tout n'est pourtant si simple que ça car pour réaliser cela :
1 - Il faut être programmeur dotnet ou avoir un programmeur dotnet sous la main.
2 - Cela nécessite d' "enregistrer l'assemblage".
3 - Pour déployer l'assemblage sur un autre poste que le sien, cela requiert des vérifications comme par exemple
quelle version de dotnet installée sur le poste? Excel 32 bits ou 64 bits ? l'option Prise en charge de la programmabilité .NET est-elle installée etc...

En conclusion l'utilisation du VBS comme le fait Patrick me semble très bien et nécessitant moins de connaissances et de conditions que l'utilisation de dotnet. Se tourner vers celui-ci que dans les cas suivants par exemple :
1 - Quelque chose que VBS ne sait pas faire. En dotnet on peut faire beaucoup de choses.
2 - Des calculs puissants. Dotnet est beaucoup plus rapide que VBS.

Ami calmant, J.P

**patricktoulon** · 20/11/2016, 12h39

re
Woaoh!! la je suis scothé!!!

créer un composant !!

c'est un idée qui me plait bien

et oui en c# c'est plus rapide c'est vrai c'était d'ailleurs mis en évidence dans ton lien

hello,
Bon, j'ai essayé le code à Patrick et il fonctionne très bien et il est très rapide. Les seuls petits bémols (très mineurs) que j'ai pu constatés :
1 - Il y a autant de processus qui tournent que d' adresses à tester.
2 - Il y a un pic d'utilisation CPU pendant la création des processus mais cela ne dure vraiment pas très longtemps.
3 - Si vous vous amusez à écrire dans des cellules de votre feuille Excel pendant la collecte, il y a plantage de quelques processus.
4 - Un fichier est créé pendant le test.

hello,
Bon, j'ai essayé le code à Patrick et il fonctionne très bien et il est très rapide. Les seuls petits bémols (très mineurs) que j'ai pu constatés :

1 - oui ben forcement le principe c'est de lancer le vbs avec pour paramètre le ping a faire .et la destination du résultat

2 -c'est tellement rapide et infime que sur la fenêtre de gestions des taches il est difficile d'en prendre la mesure d'autant plus que des que la tache est fini l'instance de wscript.exe est stopée (chez moi chaque instance entre 0 et 1.5 kilo)par rapport a une instance d'Excel il n'y a pas photo

3 - a bon je n'ai jamais constaté cela

4 - Un fichier est créé pendant le test. ben oui bien évidement il fait office d'exécutant

en tout cas je préfère de loin cette proposition a la première avec ton multitreadtool truc machin

la je dis respect!!

pour le soucis de l'utilisation du sheet pendant les procédures externes on palier au soucis en utilisant "CMD/CLIP" ca tu connais hein pour mettre les résultat et les renvoyé dans Excel seulement quand tout les pings sont passés
je regarde si je peut faire un model je métrise mal ces deux la en VBS

**davido84** · 22/11/2016, 10h20

Bonjour,
en passant par WMI : puisque l'on connaît les adresses IP à tester, autant utiliser la méthode Get au lieu de ExecQuery.
Cela évite de boucler sur l'ensemble des collections et donc de gagner du temps de traitement (enfin il me semble).

Donc en reprenant le code de Patrick :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
'utilisation de la méthode Get (évite de boucler sur toutes les collections)
Function createpingeur() ' fonction de creation du fichier vbs
    code = code & "Dim objWMIService" & vbCrLf
    code = code & "Dim objPing" & vbCrLf
    code = code & "Dim strResult" & vbCrLf
    code = code & "Set objWMIService = GetObject(""winmgmts:\\.\root\cimv2"")" & vbCrLf
    code = code & "Set objPing = objWMIService.Get(""win32_PingStatus.Address='"" &  wscript.arguments(0) & ""'"")" & vbCrLf
    code = code & "Select Case objPing.StatusCode" & vbCrLf
    code = code & "Case 0: strResult = ""Connected""" & vbCrLf
    code = code & "Case 11001: strResult = ""Buffer too small""" & vbCrLf
    code = code & "Case 11002: strResult = ""Destination net unreachable""" & vbCrLf
    code = code & "Case 11003: strResult = ""Destination host unreachable""" & vbCrLf
    code = code & "Case 11004: strResult = ""Destination protocol unreachable""" & vbCrLf
    code = code & "Case 11005: strResult = ""Destination port unreachable""" & vbCrLf
    code = code & "Case 11006: strResult = ""No resources""" & vbCrLf
    code = code & "Case 11007: strResult = ""Bad option""" & vbCrLf
    code = code & "Case 11008: strResult = ""Hardware error""" & vbCrLf
    code = code & "Case 11009: strResult = ""Packet too big""" & vbCrLf
    code = code & "Case 11010: strResult = ""Request timed out""" & vbCrLf
    code = code & "Case 11011: strResult = ""Bad request""" & vbCrLf
    code = code & "Case 11012: strResult = ""Bad route""" & vbCrLf
    code = code & "Case 11013: strResult = ""Time-To-Live (TTL) expired transit""" & vbCrLf
    code = code & "Case 11014: strResult = ""Time-To-Live (TTL) expired reassembly""" & vbCrLf
    code = code & "Case 11015: strResult = ""Parameter problem""" & vbCrLf
    code = code & "Case 11016: strResult = ""Source quench""" & vbCrLf
    code = code & "Case 11017: strResult = ""Option too big""" & vbCrLf
    code = code & "Case 11018: strResult = ""Bad destination""" & vbCrLf
    code = code & "Case 11032: strResult = ""Negotiating IPSEC""" & vbCrLf
    code = code & "Case 11050: strResult = ""General failure""" & vbCrLf
    code = code & "Case Else: strResult = ""Unknown host""" & vbCrLf
    code = code & "End Select" & vbCrLf
    code = code & "Set objPing = Nothing" & vbCrLf
    code = code & "Set objWMIService = Nothing" & vbCrLf
    code = code & "GetObject(, ""Excel.Application"").Workbooks(""" & ThisWorkbook.Name & """).Worksheets(1).Range(""B"" & WScript.Arguments(1))=strResult"
 
    x = FreeFile
    Open fichier For Output As #x
    Print #x, code
    Close #x
    'Debug.Print code
End Function

Pour info si l'on veut absolument traiter en mode asynchrone on peut tester la méthode ExecQueryAsync (toujours en utilisant VBA pour créer à la volée un fichier VBScript).
Mais dans le cas présent je ne sais pas si l'exemple tel quel s'y prête...

A+

**Oliv-** · 22/11/2016, 10h50

Bonjour,
Intéressante discussion, le gars qui a fait le Multithreading à fait un comparatif entre différentes méthodes

http://analystcave.com/excel-multith...ript-vs-c-net/

Est ce que le Multithreading fait travailler des processeurs différents en office 32 bits ?

Est-ce que l'un d'entre vous a déjà utilisé un "CLUSTER DE CALCUL" HPC ?

**patricktoulon** · 22/11/2016, 11h15

re
Bonjour oliv

Est ce que le Multithreading fait travailler des processeurs différents en office 32 bits ?

ca c'est une bonne question !!!
je vais enquêter

il me semble que l'on peut paramétrer cela dans Windows non???quand on utilise une version 32 de Windows sur pc 64

reste a savoir si une app 32 sur pc 64 fonctionne pareille

après il faut pas croire tout ce qu'on lit sur le net

exemple ici sur analystcave ils disent que les multiples sessions Excel lancé par vbs sont plus rapide que plusieurs vbs lancés
car vba est plus rapide que vbs ( si Google translate m'a bien traduit la page)

je demande a voir perso

lol et re lol !!!!

**jurassic pork** · 23/11/2016, 06h05

Hello,

Envoyé par Oliv-

Est ce que le Multithreading fait travailler des processeurs différents en office 32 bits ?

Heu tu as plusieurs processeurs dans ton PC ? où veux-tu parler des coeurs ?
En ce qui concerne les coeurs sous Windows 7 (et supérieur très probablement) :

Par défaut, Windows 7 affecte tous les cœurs à chacune des tâches en cours d’exécution, si bien qu’elles se partagent, plus ou moins équitablement, la puissance de calcul disponible.

Donc à priori si tu as des processus différents (ce qui est le cas du Multithreading Excel VBA (on lance x instances d'Excel) et VBS (on crée x processus wscript)) tous les coeurs sont utilisés si possible. J'ai fait l'essai en rajoutant les lignes de code qui saturent le cpu pendant 10 secondes dans la routine RunAsyncPing (voir précédemment dans la discussion) du test en Multithreading Excel VBA :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 Dim tempsStop As Date
   tempsStop = Now + TimeValue("00:00:10")
   While tempsStop > Now
   Wend

Avec 4 tâches lancées en parallèle (on se retrouve donc avec 5 (4 + 1) instances d'Excel) j'ai le CPU occupé à 100% et les 4 coeurs de mon QuadCore occupé à 100% pendant 10 secondes. Je suis sous windows 7 64 bits mais Excel 32 bits.

Même chose avec le code à Patrick en ajoutant au début du code VBS :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Function createpingeur()    ' fonction de creation du fichier vbs
    code = code & "Dim objPing" & vbCrLf
    code = code & "Dim objStatus" & vbCrLf
    code = code & "Dim Result " & vbCrLf
    code = code & "Dim tempsStop" & vbCrLf
    code = code & "tempsStop = Now + TimeValue(""00:00:10"")" & vbCrLf
   code = code & "While tempsStop > Now" & vbCrLf
   code = code & "Wend" & vbCrLf

Cette fois-ci il y a 4 processus wscript.exe.
Et avec l'assemblage JPdotnet même chose. Mais c'est le seul process Excel qui tourne et qui consomme tout car les tâches parallèles sont lancées dans des threads dans le code dotnet de l'assemblage.

Envoyé par Patricktoulon

exemple ici sur analystcave ils disent que les multiples sessions Excel lancé par vbs sont plus rapide que plusieurs vbs lancés
car vba est plus rapide que vbs

Effectivement le test est pipotesque car il font une boucle qui simule un calcul long. Donc en fait il teste la vitesse d'exécution du langage. Mais si les tâches qui sont lancées ne nécessitent pas beaucoup d'instructions ou de puissance de calcul du langage (le cas du ping) la ce n'est plus vrai. Il faut plus de temps à lancer une instance d'Excel qu'un processus wscript et en plus un processus wscript ça consomme moins de ressources.

Ami calmant, J.P

**Oliv-** · 23/11/2016, 10h45

Bonjour,
Je parlais effectivement de coeur, mais en fait dans le gestionnaire de taches ils parlent de UC ("Un seul graphique toutes les UC"/"Un graphique par UC")

Il ya un truc que je ne comprends pas, mon PC est équipé d'un Intel core I5 donc 4 coeurs avec W7 64b et office 10 32b

Quand je lance une boucle pour saturer Excel , j'ai mon processus Excel.exe *32 est à 25 dans Processeur

Nom : Capture.PNG
Affichages : 396
Taille : 64,4 Ko

Nom : Capture.PNG
Affichages : 396
Taille : 64,4 Ko

**jurassic pork** · 23/11/2016, 11h12

Envoyé par Oliv-

Il ya un truc que je ne comprends pas, mon PC est équipé d'un Intel core I5 donc 4 coeurs avec W7 64b et office 10 32b

Quand je lance une boucle pour saturer Excel , j'ai mon processus Excel.exe *32 est à 25 dans Processeur

la c'est normal car le VBA est monothread donc une seule instance Excel ne va pouvoir utiliser qu'un seul des 4 coeurs donc 1/4 de 100% CPU (25%)

**Oliv-** · 23/11/2016, 11h22

OK ca me va !

Comme je ne suis pas resté les bras croisés, je partage avec vous 2 liens super intéressants sur les performances de EXCEL

Performances d'Excel 2010: Amélioration des performances de calcul

et
Performances d'Excel 2010 : Conseils pour éliminer les obstacles aux performances

**Marc-L** · 23/11/2016, 11h46

Envoyé par jurassic pork

Mais si les tâches qui sont lancées ne nécessitent pas beaucoup d'instructions ou de puissance de calcul du langage (le cas du ping) la ce n'est plus vrai. Il faut plus de temps à lancer une instance d'Excel qu'un processus wscript et en plus un processus wscript ça consomme moins de ressources.

Nous sommes bien du même avis !

**patricktoulon** · 23/11/2016, 11h55

re
Ben oui c'est ce que je cris haut et fort depuis un moment déjà

si on part en vbs on reste en VBS
un instance de wscript.exe pèze moins de 2 kilos dans la liste des taches avec un fichier de 100 lignes de code avec des calculs simples
la même chose et même travail avec multitreadmachin bidule avec vbs lançant Excel et vba pour le même travail pèze de 85 a plus de 140
parti de la y a pas photo

c'est pour cela que je n'adhère pas a ce que j'ai vu sur ton lien sauf bien entendu cas de force majeure car vba a des fonction que vbs n'a pas bien sur

reste que les deux principes forcement accélèrent la cadence tout dépend du besoins( fonctions native excel ou pas)

voila voila

**Marc-L** · 23/11/2016, 11h59

J'ai vu qu'une abeille VBScript (Let It Bee) consommait ~4Mo le temps de son exécution sous Seven …

**patricktoulon** · 23/11/2016, 12h03

purée de calcul alors

ou utilisation d'object(createobject)a gogo
chez moi une requete avec xmlhttp pèze 1.45 :28,xx avec un getobject sur excel.application

les pings des fois moins de 1 kilo

Macro qui ping des serveurs lente

Macros et VBA Excel

Discussions similaires

Partager

Partager