Many SAS Viya users are aware of the capability to enable metrics at the CAS session level to display response time and resource consumption at the CAS action level. These metrics are displayed in the SAS log when run from a batch or compute server-initiated session. But if you wanted to capture these metrics and store them it may not be immediately obvious how to do so. In this article we look at a built-in way to capture them, but more importantly we review multiple use cases in leveraging them when deploying and managing SAS Viya environments.
The builtins action set has been around since SAS Viya 3.1. The history action within the action set has been around just as long. However, an internet search, both internal and external to SAS, revealed very little published content about this valuable resource. The official documentation for SAS Viya 3.5 can be found in the SAS® Viya® 3.5: System Programming Guide.
Essentially the history action allows you to “dump” the data captured about each action that has executed in the current CAS session up until the history action is executed. The data is cumulative for the session and the history action enables the user to retrieve metrics of all actions or actions at specific offsets.
The example code shown below writes the actions recorded for the current CAS session beginning with the second-most recent action (-1) and retrieves the previous 17 actions (-18). The current action (0) in the table is not selected as it is the running history action and data is not populated, as one would expect.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
The metrics included are as follows as displayed in the following snippet from SAS Studio.
Of course, it not only contains the action executed, but also the full text of the action in the command field. In addition, it includes the reason, severity and formatted_status fields which are populated during a failure. Then there are the resource metrics gathered about the system and the action such as cpuUserTime, memoryOS and memory. Some of the fields, but not all, are described in the SAS Viya 3.5 Administration: Monitoring documentation.
Here is a snippet of the data dumped by the history action on a Viya 3.5 environment. Memory fields are in bytes and time fields are in seconds. The second portion shows the formatted_status and full action command.
There is a lot of good information here but missing are timestamps and a field that provides context for the action, such as the purpose of the test. This information would have to be added after capturing the data.
Okay. You might be asking yourself, Why do I care?
If you are responsible for deploying or managing Viya environments you may have wondered if changes in the environment will impact resource consumption, performance or response time. One way to determine this is to create and maintain a suite of tests, automated of course, that run before and after changes to identify anomalies.
The test suite might be configured to access the customers data, sample datasets or both. With a series of automated tests that mimic a customer’s workload and CAS action metrics captured to measure differences you will have a fairly efficient method to assess the impact, as well as track variations over time. You may have a simple spot-check process in place, but imagine the comfort provided by a history of performance over time.
Let’s look at some use cases.
Since the process of updating software on a regular basis to pick up the latest updates is fairly straight-forward with Viya 3.x, a customer desiring to identify any impact would run a suite of tests before and after software updates. By storing the results of testing prior to software updates and then storing the results post-updates, the user has a measuring stick to determine if the software update warrants further attention.
A customer may want to add or remove a worker node from the CAS server for a variety of reasons. Maintaining and running a test suite and capturing the results before and after changes should provide some indication as to what the user will experience. One would expect adding a worker node would improve response time and if this was not the case, it would be easy to identify response times and resources by CAS action.
Using a test suite and capturing the CAS history could also be used if a customer wants to tweak their CAS configuration. Take for example one of our favorite tuning knobs, CAS_DISK_CACHE. If a customer decides they want to modify the number of directories for CAS_DISK_CACHE or place them on a faster device, capturing data from their own CAS actions would provide a good indication of any performance gains.
One key reason customers consider moving to the cloud is to manage costs. However, if they over-provision the move could be more costly than they anticipated. As more and more SAS customers move to the cloud, running a test suite in both environments and capturing the history could provide some insight into whether they are over-provisioned or not. In addition, it may highlight other potential issues with the CAS configuration.
Any existing customer that is currently running SAS Viya 3.x and plans on moving to the upcoming SAS Viya 4 release could take these steps to better understand and gain insight as to how the two environments compare. For example, if one is significantly slower than the other, is it slower for all CAS actions? Or is it just some actions?
User usage patterns and data in customer environments change regularly. As a result, another use case would involve scheduling a test and keeping a record of the history results. This could be done during a window that is fairly idle to minimize variation. The purpose is similar to the other use cases and that is to quickly identify changes, outliers and anomalies, and ultimately pinpoint where to dig further.
Finally, establishing a test suite for fresh deployments would provide a baseline for the new environment. This use case essentially is the first phase of the canary testing use case. If we have a baseline then the installer has a sense of resource consumption and response time from the very beginning of the deployment.
Of course, we want to establish a test and capture the data as quickly as possible. Therefore, it is imperative to automate as much as possible. Storing the test artifacts such as scripts and code in Git provides an easy method of retrieving the items required. Jenkins or a similar tool could be used to automate the actual tests and provide a tracking mechanism for each test. Using these tools to streamline the testing and data capture would apply to all of the above use cases, but it would be especially true of the canary testing as testing is an ongoing process.
As far as I could determine capturing this data using the history CAS action of the builtins action set is only available from a programming interface such as SAS Studio, batch or open source programming languages such as Python (I didn’t test open source but this should work as well). As a result, the sessions initiated by other SAS Viya applications would not be accessible.
Another obvious limitation is this only captures CAS actions. There are many other components to SAS Viya that are not addressed. But since CAS is the primary analytic engine for most SAS Viya solutions it is certainly a good place to start.
In some of the use cases listed above it is implied that there are two environments available for testing. This may not be the case.
And finally, CAS action testing would provide greater consistency if run during idle periods. This may not be possible, depending on the customer’s workload.
The CAS builtins.history action is a valuable capability that unveils an easy way to capture CAS action resource and response time metrics. Once captured this data could subsequently be saved in a table to provide context for comparison. The preserved table can then be used for multiple use cases to compare variations in resource consumption or response time and detect anomalies. The goal is to ultimately provide a more reliable and performant environment. Automating the testing, data capture and comparison will help provide quick results. Just keep in mind a few limitations exist.
If you’ve done anything similar to this feel free to share in the comments below.
Thanks for reading.
Hi Mark
Useful examples that I can see being of benefit in a number of scenarios. One question: how feasible is it to make this happen automatically? I'm wondering if there's a way to run this on CAS session termination but I can't see any obvious way to do this.
Alan
Hi Alan,
I had the same thought and searched briefly as well, but could not find a way to capture this information automatically. It would have to be done just before CAS termination. If anyone has thoughts on this, please share.
Mark
Join us for SAS Innovate 2025, our biggest and most exciting global event of the year, in Orlando, FL, from May 6-9. Sign up by March 14 for just $795.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.