The usage of the servers in a server-side
pool is governed by the authorization rules that are set on the servers
in the SAS metadata. Server-side pools use the ReadMetadata permission
on the server component metadata objects in the pool to control access.
Server-side pooling allows more flexibility than client-side pooling,
which limits access to a single group.
Another benefit of server-side
pooling is that workspace server load balancing functionality is automatically
built in. When a user connects to a pool, the spawner determines the
server to send the user to based on the user's access rights and on
current server loads.
By using access controls
on servers in metadata, the server that actually runs a user's job
can be controlled by the user's identity in metadata. (A server defined
in metadata, can be one or more processes that are running on one
or more machines.) Because different servers can have different command
lines, you can use server-side pooling to ensure that a user is assigned
to a server process that was launched with a specific command line.
One useful implementation of this feature is to launch server-side
pooled workspace servers that use an operating system's run priority
level.
For example, on UNIX,
an administrator might manage server performance by creating the server
with the UNIX
nice command. Lower priority
users might use a server that was launched with a higher system value
such as
5. Higher priority users might
use a server that was launched with a lower system value such as
-2.
On Windows, the administrator might manage server performance using
the
/<priority
class> option on the
start command.
(A user with a lower priority might run on a pooled workspace server
started with a start-up command that is similar to:
start/low
sas.exe. Higher priority users might run on a pooled
workspace server with a start-up command that is similar to:
start/high
sas.exe.) For more information, refer to your documentation
for the appropriate operating system.