Hello,
We currently are testing out SAS Studio Basic 3.71 in AWS. SAS is deployed on an m4.xlarge instance.
When I try logging in as a linux user, I will get a loading screen for about a minute. It then changes to initializing for a few seconds before I'm logged in.
Is there a way to decrease the amount of time it takes for users to log in? I've tried setting the max allocated memory to 4096 Mb for the appserver by modifying ${SAS_HOME}/sas/studioconfig/appserver/studio/bin/setenv.sh, but that doesn't seem to improve anything.
Thanks!
Hello @darwinwalters,
Check this out:
http://support.sas.com/kb/62/389.html
Some hotfixes should be able to help you. Check also if there is a difference when using different web browsers.
This might answer your question, regarding the memory: https://communities.sas.com/t5/Administration-and-Deployment/SAS-Studio-Loading-very-slow/td-p/36634...
If nothing from above can help you, I would check if there is anything in the spawner workspace server session that makes it slower:
https://communities.sas.com/t5/SAS-Procedures/slow-initialization/td-p/245136
http://support.sas.com/kb/59/643.html
Where geographically is your browser located compared to the SAS middle tier server. SASStudio. The request latency can really slow down login times. Check with the browser developer tools to see if it is request latency.
Logging into SASStudio essentially involves booting up some stuff in your browser with the help of the SAS middle tier and there is then a connection made to a SAS Workspace Server. Do you notice long pauses with validating the workspace your SASStudio users use when you login to SAS Management Console and validate the workspace.
If its slow in SMC its typically preassigned database libraries that slow down workspace startup times. If its fast from SMC then check the ping times to the SAS middle tier host and look into the latencys that can be recorded in the browsers developer tools.
Sorry for the delay!
my browser is close/in the same region where the EC2 instance is running.
During the initializing step, it looks like everything is loading in about 5 seconds.
However, during the 'loading' step, it looks like there is a long pause after a call to SASStudio/sasexec/sessions.
Thanks again!
After doing some digging, I found a potential issue.
I tried installing SAS Studio Basic on a new EC2 instance. When I try logging into SAS on this instance, the 'Loading' phase is significantly shorter (5 seconds vs 1 minute and 30 seconds).
One big difference that I've noticed is that the working SAS instance has NetworkManager enabled while our company's image disables it by default and configures our instances to use specific nameservers.
Would that cause an issue with the object spawner or other components of SAS Studio Basic?
EDIT: Also, unrelated, but I was thinking it might be an issue with the hostname of my EC2 instance. I've read that there is an update Host Name Reference tool under Deployment Manager, but I'm not seeing that as an option - is there something that I have to add in order to use the update host name reference?
Hello @darwinwalters, @SimonDawson,
I am sorry for taking a bit long, but I am working on the assesment of a few projects now, to be cloud-based, and I am having same kind of questions, considerations.
I might have some clues.
For starters, if I look at https://aws.amazon.com/ec2/instance-types/ I can see that the Network performance looks like:
Model vCPU* Mem (GiB) Storage Dedicated EBS Bandwidth (Mbps) Network Performance m4.large 2 8 EBS-only 450 Moderate m4.xlarge 4 16 EBS-only 750 High
While it is true that 750 Mbps is enough and high for intranet usage, it is low for a web application. SAS usually recommends 10 Gbps for the Web Applications. As far as I can remember.
In addiition, if I look to this ABSOLUTELY GREAT paper published by Margaret Crevar @MargaretC, https://www.sas.com/content/dam/SAS/support/en/sas-global-forum-proceedings/2018/1866-2018.pdf , I can see that it is recommented, in AWS, an R4 series, for Middle-tier instances.
SAS Mid-Tier and Metadata Servers These servers do not require compute-intensive resources and lesser IO bandwidth, but do require access to more memory than the SAS Compute Tiers. The recommendation is a minimum of 24 GB of physical RAM or 8 GB of physical RAM per physical core—whichever is larger.
• Amazon o R4 series (for mid-tier servers) o M series (for metadata servers) o X1e series
And now, looking back again to the AWS webpage https://aws.amazon.com/ec2/instance-types/ I can see:
Model vCPU Mem (GiB) Storage Networking Performance (Gbps) r4.large 2 15.25 EBS-Only Up to 10 r4.xlarge 4 30.5 EBS-Only Up to 10 r4.2xlarge 8 61 EBS-Only Up to 10 r4.4xlarge 16 122 EBS-Only Up to 10 r4.8xlarge 32 244 EBS-Only 10 r4.16xlarge 64 488 EBS-Only 25
Which is, network badwith wise, much closer to those 10 Gbps. Aren;t they?
In short: if you move that m4.xlarge instance to a R4 instance, I would expect your client-web connections will run MUCH faster, and according by performance benchmarks as run by SAS R&D.
I hope it helps.
Best regards,
Juan
Bandwidth on it's own is not a good measurement to give you an indication of performance. With this type of analysis I typically refer to one of my favourite books by Brendan Gregg titled Systems Performance: Enterprise and the Cloud. There is a lot to consider with this type of sizing and tuning. The best thing about the cloud is it is relatively inexpensive to experiment. Benchmarking is a subtly difficult thing to do, there are many pitfalls, and it takes a lot of work to completely understand the results of a test.
True. However, if someone has done benchmarks and tests already, such as SAS R&D and AWS together, and they a give recommendation based on those, why don't take it as a reference? 🙂
Hello @darwinwalters,
glad to hear a new instance helped with the issue of performance.
The NetworkManager should not be an issue. There is an open SAS note that mentions that, under a specific situation, NetworkManager should be better be disabled http://support.sas.com/kb/61/950.html
About the Update Hostname, that is strange. You could use also the command line tool: SASHOME/SASPlatformObjectFramework/9.4/HostPortTool.sh
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.