We have EG4.1 installed on a Citrix server for evaluation and the Sys Admins seem pretty comfortable with the performance. All the serious processing occurs on dedicated SAS9 Workspace servers.
However, they were not so happy with running sas.exe (i.e Local mode under EG) on the Citrix servers themselves. It only took 3 concurrent users running normal work before they pulled the plug on the test because of overloading.
Lastly, we have been encouraging users to always use UNC addresses (i.e. \\servername\sharename ) in any libname/filename assignments as it ensures that code is entirely portable. Pathcopy from Ninotech is free utility that helps with UNC addressing.
Main problem I've seen is with scheduling projects.
Problem 1: You've got to move the vb script to a permanent location that doesn't disappear when the user logs out. Beyond the ability of most users :-(.
Problem 2: I'm not sure if the scheduler doesn't load the users profile at all or if the scheduler runs the project before the profile has loaded, but the project doesn't run. It also screws up the users EG profile by writing an empty profile back over the existing one.
Scheduler runs ok when user is logged in - with or without EG running.
Also, currently chasing down possible permissions issue with EG add-ins on Citrix. Needs more investigation.
Since we have the intention to also allow scheduling projects, we are thankful for your comments made. Could you keep us posted about further experiences on scheduling and if you were able to circumvent the problems as mentioned.
Could you inform us some more about the permission issues you have?
Sorry for any confusion I may cause by this separate reply. I expected this reply would be "attached" to the reply made by "PMurphy" since I clicked the reply in his message rather than the one at te top of this topic.
Message was edited by: Resa @ EOM Data at Jun 6, 2006 5:02 AM
I think you could be confusing memory used by the application with memory required by the application. The .NET CLR environment is simply allowing EG to use system resources without releasing them until requested back by the system or the application is prompted to release it by user action (e.g.- minimize the app and watch almost all the memory be released.) This improves app performance by maximizing use of available resources.
For example, I just had open an EG session with several very large reports that showed EG as using 195 MB of memory. As soon as I minimized the app it dropped back down to 16 MB of memory. I then brought it back and it was at 28 MB pretty quickly.
A synopsis of the article:
Because managed code runs in the Common Language Runtime (CLR), it provides services such as automatic memory management, platform-neutrality and cross-language integration. These features streamline deployment, improve performance and provide substantial improvement to application stability.
"I think you could be confusing memory used by the application with memory required by the application. The .NET CLR environment is simply allowing EG to use system resources without releasing them until requested back by the system or the application is prompted to release it by user action (e.g.- minimize the app and watch almost all the memory be released.) This improves app performance by maximizing use of available resources. "
Thanks for the link. Yes, I'm aware of what you have posted. Nevertheless, I have seen EG machines slow to a crawl (both a standalone desktop with 512Mb memory and a Citrix server) as available memory drops away. We have upgraded memory on both PCs and Citrix servers in order to run EG. Perhaps there is a memory management issue somewhere? I need to do some evaluations comparing ActiveX/GIFs and EG3/4 to further investigate what we saw.
BTW- not all of EG 3 is .NET based, but the vast majority of the application is... Unfortunately, one of the most frequently used areas of EG, the Query task, wasn't migrated (and also streamlined and improved) to .NET until 4.1.
That said, speaking with some of my dev managers, we did find some other memory management areas in 3 that have been improved in 4.1. If you haven't migrated to 4.1, I strongly recommend it given your scenario.
Please advise with more feedback once you have a chance to review.