BookmarkSubscribeRSS Feed
Tom
Super User Tom
Super User

We are running SAS/Studio 3.5 on a Linux Grid and I find that take way too long to initiate a new session.

 

I asked our local support and got this reply.

 

I asked SAS this same question recently and they indicated that ~45 seconds is normal for the SAS Studio login process. 

 

Is that what others have also experienced?  

Any suggestsions on ways to reduce the time between entering your password to start a SAS/Studio session and being able to actual start working with it?

10 REPLIES 10
SASKiwi
PROC Star

We run SAS Studio 3.5 on non-distributed virtual / physical Windows Servers and it starts in 20 seconds. Its part of a SAS VA installation.

Tom
Super User Tom
Super User

I got this message back from my local IT.

 

Below are some steps which are performed after you click the Sign In button :

 

  • Query Metadata Server to determine whether the user is allowed to use the application or not.
  • If yes, then have the OS authenticate the user.
  • Next, connect to the SAS Application server and ask it to start a Workspace Server session.
  • SAS Application Server submits a request to LSF asking it to start the Workspace Server process. If this starts up successfully, the SAS Studio login page changes from Singing in to the blue Loading page.
  • After the first process startup has completed, the SAS App Server submits a second request to LSF asking it to start a 2nd Workspace Server process. Once this second process has completed start up is when your sign in is complete and you see the Studio application running in your browser.

 

Does anyone have any suggestions how to make any of these steps faster?

I was surprised that it seems to require launching SAS twice. 

 

 

LinusH
Tourmaline | Level 20
It would be interesting (and necessary) to see the timings in each step.
I've seen similar incredible long start-up times for Visual Analytics. But for other non web SAS clients login times are usually quick, so my gut feeling is that the web app server is to blame. Sorry if I'm being non scientific...
Data never sleeps
JuanS_OCS
Amethyst | Level 16

Hello @Tom,

 

so you are in a Grid environment. And SAS Studio starts up in 45 seconds.

 

How long does it take to SMC to validate each Workspace Server in your deployment?

How long does it take to log in to SAS Stored Process web application? or SAS VA?

 

Probably the process that takes longer (I expect, the validation of GRID Workspaces) is the one that can be improved. Do you have a lot of metadata pre-assigned libraries? Log level of workspace server? etc

Tom
Super User Tom
Super User

@JuanS_OCS wrote:

Hello @Tom,

 

so you are in a Grid environment. And SAS Studio starts up in 45 seconds.

 

How long does it take to SMC to validate each Workspace Server in your deployment?

How long does it take to log in to SAS Stored Process web application? or SAS VA?

 

Probably the process that takes longer (I expect, the validation of GRID Workspaces) is the one that can be improved. Do you have a lot of metadata pre-assigned libraries? Log level of workspace server? etc


Thanks for your note. We are not (at least I am not) using Stored Process applications or SAS VA so I cannot compare to those.

 

I was able to test different ways of just running SAS from Unix and compare that to launching SAS/Studio.

 

If I connect to one of the SAS execution nodes and just run a simple SAS program it runs in less than a second. It I have to ssh to the node first that adds about another one or two seconds.  If I want to launch DMS running on X-Windows it adds about 5 to 10 seconds.

 

If I want to use the command they have given us to start SAS via LSF then it adds another 5-10 seconds.  

 

So to me the LSF application is costing some time to get to SAS.  Of course it is also giving us load balancing and support for mulitple execution nodes and perhaps other things I don't fully understand.

 

I hope that our systems team will be able do more testing and to optimize the various pieces.

 

JuanS_OCS
Amethyst | Level 16

Hi @Tom,

 

many thanks for the update, and good luck with the investigation. Sorry I cannot help better, the only way would be to give a look into your system.

 

This thought actually brings me to a suggestion: in case this investigation takes too much time to your system admins, perhaps could be interesting to ask for a SAS Technical Consultant to come on-site and give it a look. Besides saving time, your company could save also some costs of having internal people investigating for one week, when a SAS Consultant could provide you with an answer in 4 or 8 hours. Just an idea.

dgower
Obsidian | Level 7

We are using a 5 node grid environment with LSF 7.06, SAS 9.4, and Studio 3.5.  We have 1 non-clustered middle tier server with ~100 users signed in at any given time.  All servers are Windows VMs.  We use host authentication with Kerberos and users authenticate against one of our AD domains.  Since the beginning of this implementation, it takes us 1.5 - 3 minutes from clicking sign to getting into Studio. We already installed a LSF patch that allows for the LSB_JUSAGE_UPDATE=N setting in our lsf.config file, sacrificng job-level metrics for shorter login times, which were marginal at best.  I'll look into tweaking the mbd and sbd sleep settings to try and eek out a bit more speed, but I know we've already changed those values a couple times. 

grace_sas
SAS Employee

Hi Tom,

 

SAS Technical Support can definitely help you determine where the delay occurs and what can be done to improve the logon time.  They can take a comprehensive look at your grid settings, object spawner and workspace server logs, etc.  I encourage anyone who has issues or questions about their SAS Studio logon time on Grid to open a track.

 

Regards,

Grace 

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

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.

Discussion stats
  • 10 replies
  • 1987 views
  • 6 likes
  • 8 in conversation