05-26-2012 03:22 PM
Working remotely, I was using EG 4.1 over our company VPN without issue. We recently upgraded to 4.3 and response time in EG is now unbearable - it is taking over an hour to open some of my projects, right-mouse on an object and it takes 5 minutes to open the pop-up menu, opening Query Builder on a file takes about 20 minutes.
Our tech support is not the most cooperative department in the company and complaints fell on deaf ears until I escalated the issue. They did eventually contact SAS tech support and the response was "Due to the added functionality in 4.3, we do not recommend connecting over a VPN". I can't imagine that this is the official position being taken by SAS.
Does anyone know if this could be true and, if not, what hints I could provide our tech support to resolve this issue.
Thanks in advance.
05-29-2012 08:23 AM
I've used EG 4,3 over VPN and found it to be slow, but not ridiculously slow as you describe. I would encourage you tall call SAS tech suppport yourself and see what they tell you. In the past when I've worked places where IT didn't care about supporting SAS, I found it very helpful to call SAS tech support myself, than call back the IT help desk and tell them what I was told. Cuz too often someone in IT was happy to say "SAS can't be set up that way," or "version x of that hasn't been released yet", but the folks at tech support are always wonderful, and had no problem saying "You can tell them that we said it is available, and if they want to request the installation media all they have to do is.... "
05-29-2012 09:07 AM
There is nothing about a secure VPN connection that makes SAS Enterprise Guide slower. However, a remote connection does mean that there is latency in the network connection, and that latency can affect your experience.
It should not be painfully slow as you describe it. As proof of how it can work, I point to the SAS OnDemand for Academics and SAS OnDemand for Professionals offerings, each of which use a local version of SAS Enterprise Guide to connect to a remote SAS environment (hosted by SAS) over the Internet. With a good broadband connection, the software should be usable and responsive.
When moving from EG 4.1 to 4.3, a couple of other "topology" items might have changed. EG 4.1 supported the use of a local repository for your SAS metadata (with information about how to connect to a remote workspace server, for example). While that doesn't support all of the SAS metadata-driven goodness, it does provide a lighter-weight configuration for "straight SAS" processing.
But EG 4.3 requires the use of a SAS Metadata Server when working with a remote environment, which means there is an additional connection from your client PC to the SAS environment. You've got one connection for the metadata server, and then one connection for the SAS workspace server. You might have additional connections if you work with OLAP, Stored Processes, multiple SAS workspace sessions, integrate with Web Report Studio, etc.
Also, you don't say whether your SAS connections are encrypted with SAS/SECURE. Encryption can also affect performance, although it's usually a minor effect and not noticeable by the end user.
Finally, there are a few things that you can do to help your EG session stay responsive and reduce the impact of a slow connection. Explore the options in Tools->Options and turn off all options that have EG opening data and results automatically. If you don't care about fancy ODS results, you can turn off HTML or SAS Report and just work with the Text (LISTING) output.
05-29-2012 10:33 AM
I've used EG 4.3 in batch mode over a VPN connection. That should minimize the network traffic by EG but even so, it took 60 seconds or so just to print sashelp.class to a pdf file. I would have thought this would be almost as fast as on a LAN, the script creates an EG object, that reads a syntax file, executes it on the server and that's it.
Our IT department has responded to the slow EG by installing VMware and running EG on that. Would that be a good solution or should EG on a (properly functioning) VPN be just as fast?
05-29-2012 03:10 PM
In the test case of creating a PDF file, there are a few things that happen:
- you create a small text program (fast)
- you submit the small program to SAS for processing (fast)
- SAS creates a PDF file with the result on the server (fast)
- Enterprise Guide downloads the PDF file from the remote server to the desktop, so that it can be displayed (and perhaps stored in the project file) <--- this operation is the one most sensitive to latency in the network.
As a workaround when network latency is an issue, IT departments often decide to host EG on a VMWare/Citrix/Terminal Services environment in the data center. Because EG is then co-located on the network with the SAS environment, the EG-to-SAS interactions are faster. The only content that transmits to your local desktop is the "screen scraping" of your remote EG session, and the remote desktop clients are optimized to make that a responsive experience.
The downside is that it's then less convenient to move SAS-related content to/from your local desktop. Some IT departments find that to be a Good Thing, as it keeps the data storage within their preferred policies. Some business users find it to be a nuisance, as it makes it more difficult to keep up with private copies of data and programs.
05-29-2012 03:46 PM
Actually, the program writes the pdf output to a network directory. Also, the pdf file is tiny, copying it might take 5 seconds on a real slow connection, but 60 seconds?
If I remember correctly, running a tiny batch job like this cost about the same amount of time as running EG interactively and that's slow because the GUI takes a long time to start up. It looks like the EG object created by the script has "stuff" from the GUI that it doesn't need but slows it down.
05-29-2012 04:01 PM
Just eyeballing things, it seems like the task status of "collecting" often takes the longest time, consistent with what Chris wrote. I assume this is when EG downloads the output and the log for display. Even just simple html output is a notable lag. (Of course I'm new to EG, and used to running just DMS locally, where there is no lag). Are there debugging options that would allow us to get more information on these transfer times, like a souped-up version of FULLSTIMER that would include times for uploading the program to the sever, and downloading the results and log from the server? That might be helpful to SAS admins in tuning things. Just a thought. Perhaps it's already there in the server logs, I don't have access to those...
05-29-2012 04:13 PM
The experience that you describe is not expected, nor is it typical. Personally, I often use EG over an Internet/VPN connection to work with SAS environments (hosted at SAS) and I don't see much slowdown. (Disclaimer: this is when working from home, and the SAS data center is only a few miles away.) And of course we have many students and professionals who work the same way with the SAS OnDemand offerings around the country, and as far as I know there are no widespread issues with performance. Of course, the experience may vary based on the end-user's endpoint connection and bandwidth.
If your EG sessions are running that slow and you want to try to improve it, I'd suggest working with SAS Technical Support. Aside from what was discussed here already, I can think of one known issue that might have an impact, mentioned in this SAS Note 44627. You should be able to work with tech support to learn if that is what's happening in your case.
05-29-2012 04:34 PM
Just my opinion but I think the information in that usage note is a little sparse. It says it will fix a problem with EG but it does not clearly say what version. And I''m just a ltttle concerned that someone can just install an update like this themselves. Many of the users I support are running EG 5.1 installed from a SAS 9.3TS1M1 depot and it looks like the package available from the download link is a version that is "older" than the one we are using today. I'm not sure what would happen if one of "my people" did this.
I know this is slightly off-topic becasue the OP asked specifically about EG 4.3, but I thought I'd stick my nose in.
05-29-2012 04:50 PM
I agree with your concerns. That's why I recommend working with Tech Support on this, and avoid "self diagnosis".
If you have SAS EG 5.1 or the SAS EG 4.3 that originally accompanied SAS 9.3, then this note does not apply. The "fix" mentioned is already included. It's in the SAS Integration Technologies client, a shared component that EG and other client apps use to connect to remote SAS servers.
The note applies only if you have SAS EG 4.3, installed from a 9.2-era software depot, and when you are working with a remote 9.2 or 9.3 server. There is a hotfix planned for this case -- which would be more "surgical" than the update referenced in the note.
And let me emphasize -- this problem does not affect every EG 4.3 user, or even most of them. It's very specific and Tech Support is experienced in diagnosing the issue.
06-04-2012 12:06 PM
We have been experiencing extremely slow response times with E.G. 4.3 over VPN. The issues do disappear when users from home connect to a computer that is in the network via remote desktop connection. I work from home full time connection through VPN so I just assumed everyone was having similar issues with slow response time until recently when I learned it is limited to connecting through VPN. With our upgrade to 4.3 from 4.1 we switched from a windows server environment to a linux server environmment. To add one more complication to mix we also upgraded to a grid environment so all code is run through rsubmits now.
06-04-2012 12:16 PM
You should follow the advice from Chris to contact SAS support directly.
You seem to be describing two different methods of working from home. Running on your local computer will make all connections between your PC and other computer use your VPN tunnel. These will be subjected to any speed or latency issues caused by that connection. Running on a remote computer using "remote desktop" (you might also want to look at Citrix products) means that you are actually running on a machine that is physically on the same network with the other computers. So both speed and latency issues should be reduced. Only interactions that impact what is displayed on the screen will be affected by your local computer's network connection.