EG performance - "Collecting..." takes very long

[jklaverstijn]

Hi,

I am using Eg 4.3 on Win7. My server runs 9.2M3 on a 8GB Linux X64 server w/ 1GHz LAN. I experience some serious peformance issues that I cannot explain. EG is slow to open the contents of a library in the server pane and also datasets, tasks etc. in the canvas.

Most notably is that in the task pane the phase "Collecting..." seems to take very long when running tasks. The SAS logs show that the actual SAS code is very quick to complete.

I have looked at Chris' WPF suggestions and they appear ok. So I set up logging according to note #17730. This shows a weird series of recurring messages that I cannot explain. According to the timestamps I have repeating 20s hick-ups. See below for the relevant log entries. Quite some time passes between the message "Created CPersistToOMR" and "Could not establish a connection to the SAS server on the requested machine.". Looks like time-outs. As this happens frequently the overall experience can be very annoying. I have two machines with the same symptoms.

The connection message is weird as everything basically works, just slow at times. So my metadata and workspace server can be reached. Firewall is off.

2011-03-09 18:06:32,076 [15] DEBUG SAS.BI.SASOMan [(null)] - Created persister.
2011-03-09 18:06:32,076 [15] DEBUG SAS.BI.SASOMan [(null)] - Created CPersistToOMR
2011-03-09 18:06:53,081 [15] DEBUG SAS.BI.SASOMan [(null)] - Could not establish a connection to the SAS server on the requested machine. Verify that the SAS server has been started with the -objectserver option or that the SAS spawner has been started. Verify that the port Combridge is attempting to connect to is the same as the port SAS (or the spawner) is listening on.
2011-03-09 18:06:53,081 [15] DEBUG SAS.BI.SASOMan [(null)] - SASObjectManager
2011-03-09 18:06:53,081 [15] DEBUG SAS.BI.SASOMan [(null)] - Could not establish a connection to the SAS server on the requested machine. Verify that the SAS server has been started with the -objectserver option or that the SAS spawner has been started. Verify that the port Combridge is attempting to connect to is the same as the port SAS (or the spawner) is listening on.
2011-03-09 18:06:53,081 [15] DEBUG SAS.BI.SASOMan [(null)] - SASObjectManager
2011-03-09 18:06:53,081 [15] DEBUG SAS.BI.SASOMan [(null)] - Deleted ~CPersistToOMR

2011-03-09 18:06:53,081 [15] DEBUG SAS.BI.SASOMan [(null)] - Deleted Persister.

I hope someone can shed some light on this. Thanks in advance.

Regards, Jan.

[jklaverstijn]

It's my pleasure to announce that I have resolved this by running itconfig2.exe, part of the Integration Technologies. It appeared that I had a stale default metadataserver config that was being used even when using a local server in EGuide. It mentioned a server that no longer exists.

Now that I have updated this configuration everything works blazingly fast. I'm happy and hope maybe someday someone will benefit from my search.

Regards, Jan.

[mtgbv]

Thanks Jan.
Could you explain a bit more how you changed the configuration of the server?
I have the same problem and I don't manage to solve it.

[jklaverstijn]

I didn't change anything on the server. The problem was fixed on the client side. So look on your PC for the C:\Program Files\SAS\SharedFiles\Integration Technologies\ITConfig2.exe and execute it. Be aware that on your system the path me be different.

The command is mentioned in this link: http://support.sas.com/documentation/installcenter/en/ikitclientsr/63601/PDF/default/sreq.pdf

Good luck!

[Quentin]

Hi,

I'm also having a problem with EG saying "collecting" for a long time.  Running EG 4.3 Win XP connecting to a Linux server.  If I run:

data a;
  set sashelp.shoes;
  do i=1 to 5;
    output;
  end;
run;

It takes about 4.5 seconds to run.  Most of that time it says "collecting".  I have turned off the option to automatically open data/results.  So in my head, all I think it sould be collecting is the SAS log.

As Jan suggested above, I turned on the logging per:

  http://support.sas.com/kb/17/730.html

I dont see any obvious errors.

But I did notice that about 1.7 seconds of processing time is doing something with all of the metadata libnames that are automatically assigned (and not being used).  So I see a series of blocks like:

2012-10-24 16:30:13,212 [3] DEBUG SAS.BI.SASComb.Method [(null)] - InvokeMethod::IsTemp
2012-10-24 16:30:13,212 [3] INFO  SAS.EG.SDS.Model.LibraryState [(null)] - Attach() Name = MYLIB, Status = new
2012-10-24 16:30:13,244 [3] DEBUG SAS.BI.SASComb.Method [(null)] - InvokeMethod::IsReadOnly
2012-10-24 16:30:13,244 [3] DEBUG SAS.BI.SASComb.Method [(null)] - Leaving for IsTemp
2012-10-24 16:30:13,259 [3] DEBUG SAS.BI.SASComb.Method [(null)] - InvokeMethod::UseLibref
2012-10-24 16:30:13,259 [3] DEBUG SAS.BI.SASComb.Method [(null)] - Leaving for IsReadOnly
2012-10-24 16:30:13,291 [3] DEBUG SAS.BI.SASComb.Method [(null)] - InvokeMethod::IsTemp
2012-10-24 16:30:13,291 [3] DEBUG SAS.BI.SASComb.Method [(null)] - Leaving for UseLibref
2012-10-24 16:30:13,291 [3] DEBUG SAS.BI.SASComb.Method [(null)] - Re-using object 0x16.

So my questions:

1. Does 4.5 seconds seem obscenely long EG to run that data step?   (The step itself runs on <.01 seconds, per the log).

2. Does above log suggests I am paying a huge performance price for having lots of library auto assigned (1.7 seconds for library handling /4.5 seconds for whole job = 38% !  )

3. Assuming I fail to convince the SAS admin that we don't need all thes libraries autoassigned, should they be able to set it up so that individual users can choose whether or not they want them auto assigned?  (currently if I try to unassign them from within EG, I get an error).

4. In general, are people for/against auto assigning libnames.  I had already been concerned about them because they result in bloated dictionary tables.  Given this apparent performance hit, I'm liking them even less....

I always assumed the issue was network delays, as I'm dealing with a server far away.  But seeing these logs gives me hope that the solution could be easier.

Thanks for any thoughts,

--Q.

[ChrisHemedinger]

The "Collecting results" delay is sometimes attributable to a problem in the SAS Integration Technologies client piece (a component that installs with SAS Enterprise Guide and facilitates the communication between EG and your SAS workspace).  It was a known issue in 9.2 (which played up only for certain customers for some reason) and was fixed in the 9.3 version of the client.  When I hear "Collecting results" is slow, that's the first thing that I check.

You'll have the 9.3 version already if you installed the EG 4.3 that shipped with SAS 9.3 initially, or if you have EG 5.1. Note that the 9.3 version of the SAS Int Tech client supports all backlevel versions of EG and Add-In for MS Office.

Quentin's broader question is about latency and the factors that can cause EG operations to feel slower than they ought to.  EG does chat quite a bit with the server which most users will never notice when working on a fast network.  However, if your network connection to SAS is slower, there are a few things you can do to help make EG feel a bit snappier:

- reduce the number of assigned libraries to just those that you need (per Quentin's observations)

- if you don't need ODS results, change your default output results type to Text (ODS LISTING)

- check the Tools->Options->Data performance options so that data sets do not open automatically when you add them to a project.

- similarly, turn off the option in Tools->Options->Results for opening Results automatically.

In general, as the SAS logs demonstrate, your SAS processing isn't affected by the fact that you are running via EG.  That is, DATA steps run just as fast, as do PROC steps and anything else being run in your SAS session.  In this way it's comparable to running your programs in a SAS batch session.  However, because EG must send information to SAS, and retrieve results from SAS, there is a bit of overhead that can be exaggerated when your network connection is slower.

Chris

[Quentin]

Thanks Chris,

Really appreciate your list of suggestions.

I have EG 4.3, installed when I installed 9.3 locally.  I had already turned off the automatic opening of results and data.  Will make the default output text (which will have other benefits as well, so thanks for mentioning that option).  And will have to reach out to our SAS admin to see about reducing the number of auto-assigned libraries. 

Ultimately, will keep the pressure on my friends in IT to keep looking for any obvious molasses in the network connection.  On occasion I have been able to remote desktop into a Windows box that is closer to the SAS server, and when I do that, EG is much snappier.

--Q.

[Doc_Duke]

Q,

This is key evidence to a network issue:  "On occasion I have been able to remote desktop into a Windows box that is closer to the SAS server, and when I do that, EG is much snappier."  It may be "by design" (remote offices are connected via slower lines) or it may be a technical problem (e.g. bad switch in the wiring).  Technical problems may be hard to find, but they are often easier to fix.

Doc Muhlbaier

Duke

[Shashia]

Hi jklaverstijn/ Chris/ Hardy,

Thanks a lot for this posts. I have followed this thread and similar threads and am facing a similar but rather strange issue:

I have EG4.3 installed which connects to a SAS 9.2 server, both located on my LOCAL machine... In effect, when I open my SAS EG 4.3, I just connect to server LOCAL.

- The connection happens in less than a second when I am not connected to any network (LAN off and WLAN off).

- The connection happens in 2-3 seconds when I am connected to my office network

- The connection takes about 2 minutes when I am connected from my home network

Not only this, every SAS procedure takes almost 2 minutes to execute when I am connected to any other network  other than my office network. Its frustrating to see simple PROC REG statements with 24 observations taking 2 minutes to run. And that too, both the EG and SAS 9.2 are installed on my system itself.

I have tried itconfig2.exe and have determined that SAS EG uses a COM connection to connect to SAS base. But I am not able to figure out the cause for the delay. As of now, the only solution I have is to work at home with WIFI/LAN switched off. Any pointers/suggestions into what causes this would be very much appreciated.

Thanks

Shashi

[HardyThomas]

Hi All

I have a similar problem, intermittent as it is, EG 4.3 waits forever (in effect 'hangs').  I have tried various things but to no avail.

So any help would be appreciated. For some reason I cannot find ITConfig2.exe anyhwere!!

I have gone through a reinstall of SAS as well but not help.

Bye for now.

Hardy Thomas.

[jklaverstijn]

Hardy,

Many times a company's network infrastructure has components (mainly routers, firewalls) that discard network connections after a set idle time. I have seen this affecting EG much the same way as you describe. Both connections to metadata and workspace servers can be forcefully terminated by this and render EG unresponsive. Maybe you can talk to your network folks to work this out. It worked for us. I hope this can help resolving your issue.

- Jan

[HardyThomas]

Hi Jan,

Thanks for the reply.  I will take that up and see with Network Admin. what can be done on that as a possible solution.

It's just that I have had, following various install hiccups, to get in touch with the SAS UK team and had the entire SAS Depot of 17GB downloaded to my own machine and then proeeded with a full install on my machine - not from a network.  So I presume no network 'effects' should be affecting my SAS EG performance.  Furthermore, I do not use, as far as I am aware, any network servers for workspace.  All processing is done on the local server.  I have, however, little grasp of the metadata server and what for and why it is needed or how it should be configured, at the moment. In any case, the metadata server should also reside on the 'local' server, I should presume, given the way in which I installed SAS EG.

Nevertheless, of course, SAS EG may well still be attempting to connect/reconnect to said 'phantom' servers.  This will be so,  if these server locations were included automatically as 'default locations' in the install phase, as the servers SAS EG should be connected to (and which server locations may need to be either set locally or may need to be deleted as the case maybe).  For exmaple, if they do not exist or are not needed.  I am, however, unaware of these details.  Although from your previous post (and of Chris and Quentin) it does seem as though there are such 'default' settings that refer to phantom server locations.

Any thoughts would help.  I will chase it up anyways.

Thanks.

Bye for now.

Hardy.

[jklaverstijn]

Hi Hardy,

I am out of suggestions. If everything runs from the local server and is a fresh install (assuming SAS 9.3 and EG 5.1) then network issues are indeed unlikely. I would keep an eye on the load you're imposing on your machine. Maybe it's underpowered for the task. All I can (and must) suggest is to contact tech support again if you really think something is wrong.

Good luck,

- Jan

[TomKari]

Hi Hardy

One thing I've seen is that if you're requesting results as HTML, and the result is very large (more than 10,000 rows), even though SAS runs very quickly, it takes forever to get the HTML back to your PC and open it.

Tom

[HardyThomas]

Hi Tom,

Thanks for the reply.

I see your point.  I am not, however, requesting the output in html format.  I have only the SAS Report box 'abled'.

My Results General options are at the moment as follows:

Replace without prompting.

Display SAS log when errors occur

Automatically open data or results when generated

Link handcoded ODS results

Change task icon when warnings occur

Generate ODS statements

I have set the results limit prompt to 15MB and 50 as the max output data sets.   I am usually at around 40-50 for datasets n each run - so that is not an issue, but can be changed anyway if needed.

Any further thoughts you may have on this waiting time to 'Colleting ...' will be of help.

Thanks.

Bye for now;

Hardy.