You didn't mention
- The used OS, Can be Windows or a Linux (*Unix) type.
- Where the SASapp servers are configure and run
- How the authentication is done. Host based as most reliable or some tricky one using shared accounts or IWA
- What has done at the VM virtualization level.
- The network access layer to those machines (firewalls&speed)
Peforrmance&tuning is a difficult topic as it is requiring understanding of all the involved interactions. This is more complicated with virtualization.
There is not much on that with SAS. If you want the best out of your hardware the bare metal is the limitation. Licensing is another issue, you could come into paying for all the hardware where you are expecting the virtualized limit is the one having being agreed on. Check that with your legal affairs (procurement).
Two nice papers:
- http://www.vmware.com/files/pdf/techpaper/vmw-sas-moving-virtual-environment.pdf
- http://www.vmware.com/files/pdf/mem_mgmt_perf_vsphere5.pdf
The first nasty one is having a good communication with the VM-guys. Your OS with SAS is just an application for them. They can have ideas of common application settings that are not a fit with SAS usage.
The firewalls&speed can become an issue (note the NIC VM setting) but that is more likely not the biggest one.
To eliminate that one can be difficult (needing measurements). The first step is having an other RDP ore terminal you can work on the machines seeing what is happening.
"Well with one user working it is looking to work well. That is your installation verification all well project successful. Two or more processes and that is not performing well? User isse not the installation/configuration." Here you have your challenge in expectations and trying solving those is a hard job.
You are saying two things:
1- When clients (2-4 at the same time) try to run codes/query from EG7.1 it runs slow (processing IO - cpu)
2- When trying to connect. start run from EG7.1 it is slow (metadata login and start a sas process on the os level) .
Issue1 is a resource CPU/IO/Memory issue not able to deliver sufficient of those by the VM for each of your sas processes.
As your are talking about Eguide, the midtier is not involved. Only the metadataserver and the app-server more dedicated the WS are the ones to look at.
What is happening on the OS-level that is holding up your sas-processes. It could be thrashing (memory constraints) IO limits or concurrent process limits (cpu).
Issue2 can be a resource issue but also other things. As some resource issue the metadataserver can be suffering from lack of resources so that one becoming a problem to deliver fast.
The start (login) does several things that depends on how authentication is done. The metadataserver is running a process on a very high privilege level (unix sasauth) for that. Whtn that authentication process is suffering from something the logins will be delayed. You could eliminate that by defining an internal user and using SMC or something like PLM with that. When they behave well but the login EGuide is problematic than there is an internal SAS issue with the login and the following start of a OS sub-process.
These days an invalid login is followed with a delay for a retry. What if that delay is done on behalf of the metdataserver generic process not the involved user proces. That one can be seen be checking the login steps with 39891 - Using PROC PERMTEST to diagnose UNIX host authentication issues in SAS® 9.2 and later releas...
---->-- ja karman --<-----
