Unlike SAS EG or Display Manager, which both run in a single workspace server process, most actions performed in DI Studio trigger a separate process. In a traditional setup this doesn’t cause a noticeable delay, but a SAS GRID setup is designed for efficient execution of long-running jobs, not for fast start-up of new processes. The Grid Manager uses anything from 10 seconds depending on the actual configuration, before a process begins execution, no matter how long the process runs before completion.
This latency time before anything happens is very frustrating for DI Studio users. If record count is enabled in DI Studio, which in most cases is very convenient, just clicking on a table to see its properties causes this delay, amd much of the time used in DI Studio is spent waiting for the Grid manager to wake up, select a server and initiate the process. In theory, there is a similar latency problem in batch execution, where most of the several thousand jobs running in the daily batch are completed in a few seconds or less, but we have so much excess capacity that it’s not a problem.
According to our SAS Consultants everything has been done to reduce the problem by configuring grid queues, but there seems to be an inherent mismatch between the working principles of DI Studio and SAS Grid, and I write this hoping for a good idea, as we can’t be the only installation with this problem. I have thought of circumventing the Grid Manager and reserve one server in daytime to serve DI Studio users using a specially configured workspace server, but I don’t know if it’s a good idea or even feasible.
I am looking forward to answers from others having the same problem, and I hope they will share their experiences and solutions.
Hi @ErikLund_Jensen ,
great topic, I am working with this topic for a while and I would like to drop a couple of further questions, what I know, and I would love to hear what you and others have to say in this regard.
First of all, a few questions for you and anyone who answers here:
Now, my personal answers in my current Grid:
Now, here is what I know:
Does anything of this help? Looking forward for thoughts!
Best regards, Juan
Thanks for your answer. Our current SAS setup is DI Studio is 4.903 and (serverside) RHEL 7.4 / SAS V940m5a / IBM Spectrum LSF 10.1.0. We have data and SAS work / utilloc areas shared between 5 physical grid servers on a very fast solid state file system.
So you think the latency may be due to the authentication process. We never thought of that, but have so far only had the grid manager's handling of initial connections and spawned sessions in focus. Unfortunately authentication is not my core competence, but the twin-headed monster Cerberus is part of it. I will give this idea to our very competent SAS technical representative. He happens to be on the premises tomorrow, and I will let you know what happens further.
Thanks for your continuing interest in this matter.
Our SAS technical consultant can't see how a 5-10 second delay could be caused by the authentication process. His next move will be to set up an extra server context bypassing the grid, so we can test if that makes any difference in how long it takes to establish a connection from a client Display Manager session.
I hope we can squeeze that in before an upgrade to M6. and I will let you know what happens.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.
Find more tutorials on the SAS Users YouTube channel.