Capacity Planning

As an Application Performance Engineer, I am responsible for monitoring and ensuring that my application delivery platform is performing well for our users/customers. But, of course, that means that my Login Enterprise must not be experiencing performance issues.

When I inherited the PerfEng role at Rightworks, there was a lot of discovery that I had to do. And as we continue to expand the number of applications, customers and Session Hosts, I needed a way to ensure that I wasn’t at or approaching capacity. I wanted to be proactive and not wait for a slew of “There are currently no launchers/accounts available” messages filling up my Event queue.

So, I wrote a couple of scripts to give me an idea of what my concurrent usage was for Accounts and Launchers.

Powershell

So, like most of you, I am using Powershell to access the Login Enterprise API. My Powershell-fu is getting much stronger since I started at Rightworks. I attribute this to both, the team that I work with (some really smart people here) and my need for information/automation increasing.

Most of our scripts are based on the LoginEnterpriseFunctions.ps1 file on the Login VSI Support page. Powershell Script with Functions to control and extract data from Login Enterprise – Login VSI. Its been a great tool to see how to compose scripts for our needs. Keep in mind that this hasn’t been updated in quite a while, so some of the things will need to be updated.

A couple of things that I’ll note here:

• These scripts are written API v4, which has been deprecated as of Login Enterprise 4.10. So, you’ll need to update the Uri string in the API call from v4 to whichever version you wish to use. I have been using the v7-preview to kind of future-proof my scripts.

$Parameters = @{
    Uri         = 'https://' + $global:fqdn + '/publicApi/v6-preview/launchers'

• With the new API, you may have to change how you designate Ascending/Descending. The older APIs use the full word, but the newer ones use Asc/Desc instead.

My standard disclaimer applies that my Powershell-fu is still immature and you may have more elegant/efficient ways of coding. 🙂

Launchers

First, a little background on how are our systems are laid out. We have 3 datacenters hosting RDS session hosts. In each data center we have a separate Login Enterprise environment. In 2 of our datacenters, we are hosting 4 different application pools. In the third datacenter, all 300+ session hosts are delivering the same application set.

DC1 has 39 launchers, DC2 has 29 launchers and DC3 has 20 launchers. All launchers are being used by all continuous tests.

So, using the Get-Launchers function in the Functions library, I assign that to an array. Then, I iterate through the array and write out the sessions value for each launcher. I’m writing this to a CSV file, as designated at the top of the script ($export).

Using a While loop, I query and write this out every 5 minutes.

ForEach ($launcher in $launchers) {
    # Header
    $launcher.machinename + "," | Out-File $export -Append -NoNewLine

}
"" | Out-File $export -Append
While ($true) {
    Get-Date -format "ddMMMyyyy HH:mm:ss"| Out-File $export -Append -NoNewLine
    "," | Out-File $export -Append -NoNewLine
    $launchers = Get-Launchers
    ForEach ($launcher in $launchers) {
        $launcher.sessions.ToString() + "," | Out-File $export -Append -NoNewLine
    }
   "" | Out-File $export -Append
   Start-Sleep -Seconds 300
   }

This allows me to get a running tally of the number of sessions running on the launchers. In my case, we were well under the 30 sessions recommended maximum.

Accounts

I needed to do the same for my accounts. The difference is that we are using separate account groups for each pool of applications. As we are constantly expanding the number of servers hosting applications, I want to make sure that we have enough accounts available.

Using the same methodology, I used the Get -LEAccountGroups function. Originally, I thought that I would have to get a list of Account Groups and then for each Account Group, get the list of members and then check the InUse value for each account.

Thankfully, it was much simpler than that. By setting the ‘include’ parameter to ‘member’, the function will actually provide the members for each Account Group. So, one less loop/call to do! 🙂

Then, it was simply a matter of selecting all of the accounts in each group that the InUse value was set to ‘True’ into a new object and use the .count function for that object.

I also decided to include the total number of accounts in that group.

Using the While loop to keep recording this every 5 minutes.

Summary

These have been a real help for us at Rightworks. Hopefully, this provides some inspiration for some tools that you might need in your environment. Here are the scripts in full.