In the previous SAO article, I talked about capacity utilization, a key metric, especially for shared licenses. I will discuss additional metrics, how they can provide objective utilization measures, and what role they can play in decision making – which is always about maintaining an optimal software license inventory.
Altair SAO provides a year-to-date (YTD) Summary Usage Report. It should be inspected every 6 months or longer. This report provides a numerical summary of about 15 metrics for every software feature in the system that has some usage, and allows for inspecting outliers of every metric. You may drill down to further inspect usage patterns in detail. The following diagram shows a few important metrics that warrant close inspection:
This metric refers to the total available licenses in the system for a software feature, and the associate peak license usage. Comparison of peak with total available licenses can easily identify software features that have excessive license inventory.
2. Distinct Users
This measure shows the total number of distinct users who accessed a software feature. If the current license inventory serves a percentage of total users (Distinct Users/Total Users), and the user count in the future is expected to change, a new estimate for Distinct Users can be calculated and applied to the license count.
3. Daily Usage Variance
This describes the daily usage profile. For batch jobs, this is typically very close to a circle with a very small standard deviation, which will be a small fraction of the average. If it is not, high-performance computing (HPC) tuning, job submission parameter tuning, and license inventory tuning is warranted.
4. Run Duration
This metric measures the average run duration and maximum run duration. It can be used to group users into different usage categories like Small, Medium, Large or similar.
There are two important measures, Raw Denials total and Effective denials. When a user gets a denial of service, many times, the user tries to get a license multiple times in a short duration, which in reality can be considered as one denial. Effective denials can be estimated using some algorithms that can include heuristics.
In most cases, a software feature checks out a set number of tokens. Some software features check out a variable number of tokens through the lifecycle of 1 run. Tokens per run provides an average number of tokens used by the software. This metric can be used to estimate future token needs (license counts).
1. Number of Runs
This is a simple count of how many times a software feature was executed. It can be used to compare relative usage with respect to other similar software features.
2. Licenses/Distinct User
One can use this metric in conjunction with the denials to estimate if the current licensing levels are adequate for the user group.
This metric can be used by a company to determine its threshold of denials tolerance. For example, if there were 1 denial for every 2 runs, perhaps they have too few licenses. A company might decide that its denial tolerance is 5% (tolerate 5 effective denials for 100 runs).
4. Total Usage
This metric allows companies to know which software features are used the most.
5. Maximum Saturation %
Saturation % is defined as PEAK/Available licenses. If the PEAK is equal to the total available license, the features is running at 100% saturation, and another request for a license will result in a denial. This metric will show which software features ran at high saturation levels during the reporting time-span.
I will discuss each of these metrics at length in a series of future posts.