Management Console, Linux and Terminal Emulation

[KimLeBouton]

SAS Deployment Community:

I’m trying to get feedback from others on using SAS Management Console (SMC) from a Linux server, which is located off-site.  SMC is painfully slow to load and also use.

I’m not having as much problems running the SAS Display Manager from the Linux server, although it is a little slower than our AIX server (located at the same off-site facility).

Primary Specs

• Management console—SAS 9.3
• Linux—SUSE Linux Enterprise Server 11
• SSH Client—SecureCRT 5.0 (As I’ve been writing this note, I found that SecureCRT has a product for Linux too.  I’m requesting a test copy.)
• Terminal Emulation—Exceed Version 11 (Aside:  I can access another emulation software product, but it seemed equally slow too.  Since I’ve used Exceed for years, I’d prefer to stick with it.)

Secondary Spec

• gnome is easily available and loads up very fast

SAS Technical Support has suggested using the Window desktop version SMC to manage this server.  Is this what others use when supporting a Linux server?  The application developer would prefer to use SMC on the actual server, via SSH Client and Exceed.

A very useful source for deployment: I found this several days ago on platformadmin.com, http://platformadmin.com/blogs/paul/2012/04/sas-management-console-over-ssh/.  I will try this slightly alternate access method next week, but it is very similar to what we are already doing.

Thanks in advance for any suggestions,

Kim LeBouton

KJL Computing

[Quentin]

Hi,

I won't be much help (I'm not an admin), but just curious.  Are other BI clients (EG, DI Studio, etc) also painfully slow?

We have an offsite linux server.  And when we run Windows clients locally they are all painful (WRS/ SPWA is ok).

After the usual battles (network people say the application is sending too much data, application people say the network is too slow), our eventual solution (suggested by SAS), was to set up a windows server next to the linux server.  And we use remote desktop to log into the windows server, then run Windows version SMC/EG/DI studio there.  It's a bit of a hassle, but works much faster.  Again, that's my perspective as a developer, not an admin.

--Q.

[jakarman · Accepted solution]

Kim, This is an area full of emotions. The research performance issues it is important to understand the whole chain of components and those effects.

What you have is a BI/DI intelligence platform  is built around:

- metadataserver (Linux) .  It will run actually a SAS/Base Foundation process. It is setup to work memory based.

  Inside you will find a lot of java and xml usage. Taht are not the fastest well performing parts.

- a webserver with a JAVA-container for webclients (WRS Portal etc)

- Computeservers defined as logical app-servers started by the objectspawner 

- (and more)

You can place all these serversides all on one server or for load/performance spread them over multiple machines.

- The desktop clients like EG, Amo (.Net) based and java-clients SMC DI EMiner etc.

All is installed mostly using the SDW tool and components are place conforming this way according plans.

SMC is run by a JVM environment. Assuming using JAVA would make you independent of the versions of java is wrong.

Using a wrong java version by type 32/64 bit or version or source, Oracle or other can give a lot of problems. 

SMC is also not a simple tool as is. It will get a lot of plug-ins added coming in from the other clients DI Eminer etc. What happens is that java classes are added to it in dedicated submaps. Eminer, DI, Information Map Studi, and others are not supported on Unix environments.

Metacoda | productivity through metadata visibility (paul Homes - platform admin) is delivering more of this stuff on it, that part is more options on metadata management.

Knowing this, it is very common to use all the desktop java clients including SMC from the Windows desktop.

A SAS DMS with X-11 is still working (9.3) but has a lot of challenges. It is fast enough when the graphical traffic in not encrypted.
Getting to Unix engineers and security guys they will block this. X11 is positioned as not being secure and the traffic should tunneled encrypted. 

With SAS 9.4 all is required tob 64-bit on Windows and newer Windows versions and X11 are getting more into trouble. See the requirements

SAS 9.4 Install Center Documentation. Slowly slowly you are getting forced to leave the old approach.

Eguide, AMO, SAS VA, Web based  etc are the new ways of using SAS.      

I do not know what you mean with "the application developer" it looks to be a guy that is installing SAS.
That is normal a "SAS platform Admin"  like: SAS admins: providing maximum benefit to users - SAS Users Groups

An application developer that is the guy I am seeing the one is delivering the code in .sas files running your business questions.

Problems in a Windows desktop (the clients) can be that they have been set up with too small sizing of resources. Often this is done by desktop virtualization approaches.

Eguide is integrating in Office as is AMO you would like to have them together. JVM is a virtual machine needing his own resources as guest in the Windows OS. 

When all is influenced by virusscanners encrytion firewalls it is rather easy to get into a out resources too slow performance situation.

Moving the windows clients to a Windows-server with a Terminal Server is an easy get away of the desktop and network administrators.

All normal policies applied to the desktops should propagated to this terminal usage solution.
When the internal policies are not allowing or supporting this approach you have a next challenge to solve.

[PaulHomes]

Hi Kim,

When I work remotely I tend to establish a VPN connection and run SAS Management Console locally on my workstation and then connect to the remote server. It's by no means fast, but is quite usable.  I tend to do this more from habit than anything else, and the fact I have all the profiles and settings already configured on my workstation anyway. An RDP / terminal server session should perform ok too - I just don't tend to run it that way when I'm connecting to Linux servers.

I have also found that SAS Management Console when run remotely and displayed locally via ssh with X forwarding over a slowish connection is very slow.  Because the term "slow" can be very subjective I've captured some rough timings for comparison.

I used a workstation with a 3G mobile broadband connection to a remote network (containing a SAS 9.3 server) which itself was connected via an ADSL modem. To give you an idea of the network performance an SCP of a 10MB file from the client to the server took about 1.5m (~120KB/s) and back from the server to the client about 2m (~90KB/s). i.e. not a very fast connection.

These are some timings from running SAS Management Console on the remote Linux server via ssh with X fowarding to the local workstation over this 3G mobile broadband connection:

• sasmc command line to login dialog: 1m38s
• login dialog connection to usable SAS MC session: 2m31s
• switch from plugins to folders tab: 40s
• select a different folder in folders tab: 37s

This was quite painful and I'm guessing you were getting similar results.  I did some Googling and saw that Java apps have historically had user interface performance problems when run remotely over SSH with X forwarding. There are some settings that can be tweaked but I think a VPN connection is simpler (if you can get one).

For comparison here are some timings for running SAS MC on a local workstation connecting to the remote SAS server over a VPN over the same 3G mobile broadband connection:

• Running SAS MC on a local Linux workstation with a VPN connection to the server network:
  • sasmc command line to login dialog: 8s
  • login dialog connection to usable SAS MC session: 1m58s
  • switch from plugins to folders tab: 5s
  • select a different folder in folders tab: 6s
• Running SAS MC on a local Windows workstation with a VPN connection to the server network:
  • from clicking shortcut to login dialog: 5s
  • login dialog connection to usable SAS MC session: 1m55s
  • switch from plugins to folders tab: 5s
  • select a different folder in folders tab: 5s

In this case, when using SAS MC locally and connecting remotely over a VPN, whilst the initial connection is similar (a little bit faster), moving around in the local SAS MC is much faster (than the remote SAS MC via ssh with X forwarding).  I would suggest you try that method to see if you get similar results. Alternatively, as Quentin and Jaap have suggested, RDP into a Windows server in the remote network and run SAS MC on that remote Windows server (after installing the SAS clients on it).

I hope this info helps you with your choices.

Cheers

Paul

[ronan]

Hi,

I won't contribute directly to this thorny issue as regards performance according to network access. Instead I'd like to add a short advice

about the SMC running on Linux versus Windows:

The Library Manager of the Unix version lacks a feature of its Windows counterpart since you cannot (manually) register new tables references with the Unix Plug-ins; to perform this task, you'll have to run the SMC on Windows.

Of course, Metalib procedure and/or SAS EG can override this quite easily but I still think this should to be considered when choosing the appropriate environement to run your SMC.

I don't know if this functionality has been ported to Unix/Linux in 9.4 but it is still lacking in 9.3 :

- does anybody know ?

Ronan