Optimized PowerShell performance with Cisco UCS PowerTool

imageIn the last post I gave a quick overview of one of the many cool features of the Cisco UCS PowerTool PowerShell Module, I showed how they had made it easy for the admin to pick up their toolkit and use it, how navigation over 1000+ cmdlets could be made easier, if you didn’t read it then you can find the post here.

I quickly realized this was not going to be a one blog post affair as there are so many great features in this PowerShell module which impressed me, features I have not seen before in PowerShell (I may be wrong).

How fast is your code ?

One thing I have seen both developers and scripters fight with is the speed at which things can be done, most times when not using PowerShell to just manage the local machine there is an element of accessing an external system.  There are many ways you can access these external systems depending on the company and the way the cmdlets are written.  Its great that PowerShell often has a certain amount of caching, when objects are retrieved from the remote systems or machines they can be altered locally and then sent back to the original destination.

It’s the sending back and retrieving information which can often cause some PowerShell cmdlets to be slow when working on large systems or when working with multiple systems.  Developers of PowerShell Modules and snapins often do a great job of optimizing this to make things faster.

In Cisco UCS PowerTool I saw a method I had not seen before which I thought was both a very system admin friendly and also optimized way of doing this.

The following example code shows how to create a simple boot policy, for the purpose of this post it doesn’t really matter what the code looks like but keep in mind that after the end of each line, and during the line there will be calls to the Cisco UCS API retrieving and setting data, at the end of the below code we may have called the API around 10 times, add this up into a more complex piece of code and then ask it to work on multiple systems and our external calls soon mount up, each external call having an impact on the final speed of the script.

$BootPolicy = Get-UcsOrg -Level root  | Add-UcsBootPolicy -Descr "Test Boot Policy" -EnforceVnicName "no" -Name "Test-BootPol" -RebootOnUpdate "no"
$BootLan = $BootPolicy | Add-UcsLsbootLan -ModifyPresent -Order "2" -Prot "pxe"
$BootLan | Add-UcsLsbootLanImagePath -BootIpPolicyName "" -ISCSIVnicName "" -ImgPolicyName "" -ImgSecPolicyName "" -ProvSrvPolicyName "" -Type "primary" -VnicName "1"
$BootPolicy | Add-UcsLsbootVirtualMedia -Access "read-only" -Order "1"
$BootStorage = $BootPolicy | Add-UcsLsbootStorage -ModifyPresent -Order "3"
$BootSanImage = $BootStorage | Add-UcsLsbootSanImage -Type "primary" -VnicName "0"
$BootSanImage | Add-UcsLsbootSanImagePath -Lun 0 -Type "primary" -Wwn "20:00:00:00:00:00:C0:00"

How Cisco makes this faster

The Cisco UCS PowerTool team have put some thought into this and as well as the performance enhancements built into the cmdlets they have also introduced a couple of cmdlets to allow you to make a single optimized call to the API – this is a fantastic idea as you can basically build up your code in a nice block and then send it all, optimized for the API in one call to the Cisco UCS API.

Lets take a look at our second example of this code:

Start-UcsTransaction
	$BootPolicy = Get-UcsOrg -Level root  | Add-UcsBootPolicy -Descr "Test Boot Policy" -EnforceVnicName "no" -Name "Test-BootPol" -RebootOnUpdate "no"
	$BootLan = $BootPolicy | Add-UcsLsbootLan -ModifyPresent -Order "2" -Prot "pxe"
	$BootLan | Add-UcsLsbootLanImagePath -BootIpPolicyName "" -ISCSIVnicName "" -ImgPolicyName "" -ImgSecPolicyName "" -ProvSrvPolicyName "" -Type "primary" -VnicName "1"
	$BootPolicy | Add-UcsLsbootVirtualMedia -Access "read-only" -Order "1"
	$BootStorage = $BootPolicy | Add-UcsLsbootStorage -ModifyPresent -Order "3"
	$BootSanImage = $BootStorage | Add-UcsLsbootSanImage -Type "primary" -VnicName "0"
	$BootSanImage | Add-UcsLsbootSanImagePath -Lun 0 -Type "primary" -Wwn "20:00:00:00:00:00:C0:00"
Complete-UcsTransaction

I feel the need, the need for speed**

** Anytime you can get a movie reference in a blog post its gotta be worth it Winking smile

As you can see from the above code, we have added a Start-UcsTransaction at the start and a End-UcsTransaction at the end, so what does this do ?

It allows all the code in between these statements to be gathered by the Cisco UCS PowerTool and optimized, then at the end one call is made to the API sending the complete data.

Performance boost or what ?!

I think the benefits of this are clear, more efficient, optimized and less frequent calls to the API can only mean faster code.

I think its great that Microsoft created PowerShell and third parties are continuing to pick it up as it becomes the default scripting language for the datacenter, in my eyes this is one area where a third party company has taken a fresh new look at the way things are performed and made a clear enhancement.  Very cool stuff, and there is more to come in further posts, I haven’t even got to the best feature yet !

2 thoughts on “Optimized PowerShell performance with Cisco UCS PowerTool

Leave a Reply to thedogsofmars

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.