Slow execution of workflows

Jun 28, 2011 at 6:27 PM

There is a common issue that running PowerCLI cmdlets on 64-bit PowerShell takes longer than running the same cmdlet from a 32-bit PowerShell console.  When testing the vSphere IP, I am seeing the same lag as if it were running in a 64-bit context.  I'm looking for more information.  Can someone verify whether 32 or 64 bit is being used?  I searched elsewhere and Opalis supposedly is running PowerShell cmdlets in a 32-bit context because it is a 32-bit program, but that is not in keeping with what I am experiencing.

Jun 28, 2011 at 10:14 PM

Hey Will,

I believe that the lag that is seen using the IP objects is due to connection time. Each object has to connect and disconnect from the VMWare environment which takes time (negotiation etc). There is not a way that I know of to share a common connection amongst all of the objects in a policy. I am looking into / working with the PG to see if this is possible (I think it should be as each policy instance is in the same process instance so they *should* be able to ‘know’ if they are already connected or not.

-Ryan

From: wprather [email removed]
Sent: Tuesday, June 28, 2011 12:28 PM
To: Ryan Andorfer
Subject: Slow execution of workflows [OpalisVMWareIP:263131]

From: wprather

There is a common issue that running PowerCLI cmdlets on 64-bit PowerShell takes longer than running the same cmdlet from a 32-bit PowerShell console. When testing the vSphere IP, I am seeing the same lag as if it were running in a 64-bit context. I'm looking for more information. Can someone verify whether 32 or 64 bit is being used? I searched elsewhere and Opalis supposedly is running PowerShell cmdlets in a 32-bit context because it is a 32-bit program, but that is not in keeping with what I am experiencing.

Jun 28, 2011 at 11:28 PM

It would be really cool to persist connection like that within a policy.  I am exploring Opalis during my internship to see what it can do, so I am only a beginner to Opalis at this point.  I understand perfectly what you are referring to. To give you more insight into what I am running into though...

Just using a simple get Virtual Machine object takes one minute and 59 seconds every time without fail.  Naturally to do that it is doing a connect-viserver as well as a get-vm command.  Both of these take a while the first time they are executed.  I included some times below to illustrate what I am talking about.  The times it is taking through Opalis seems more like a 64-bit call.  This may be just for informational purposes and beyond the extent of what we can handle here.  I was initially just curious about forcing the commands to execute in a 32-bit context.

Will

32-bit PowerCLI

> measure-command -expression {connect-viserver $myVServer}
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 6
Milliseconds      : 557
Ticks             : 65576236
TotalDays         : 7.58984212962963E-05
TotalHours        : 0.00182156211111111
TotalMinutes      : 0.109293726666667
TotalSeconds      : 6.5576236
TotalMilliseconds : 6557.6236

> measure-command -expression {get-vm willtest}
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 7
Milliseconds      : 776
Ticks             : 77762659
TotalDays         : 9.00030775462963E-05
TotalHours        : 0.00216007386111111
TotalMinutes      : 0.129604431666667
TotalSeconds      : 7.7762659
TotalMilliseconds : 7776.2659

64-bit PowerCLI

> measure-command -expression {connect-viserver $myVServer}
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 25
Milliseconds      : 12
Ticks             : 250125138
TotalDays         : 0.0002894966875
TotalHours        : 0.0069479205
TotalMinutes      : 0.41687523
TotalSeconds      : 25.0125138
TotalMilliseconds : 25012.5138

> measure-command -expression {get-vm willtest}
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 39
Milliseconds      : 228
Ticks             : 392287237
TotalDays         : 0.000454036153935185
TotalHours        : 0.0108968676944444
TotalMinutes      : 0.653812061666667
TotalSeconds      : 39.2287237
TotalMilliseconds : 39228.7237

This discussion on VMware's site will actually give you a better idea of the issue I think is going on.

http://communities.vmware.com/message/1775829#1775829