Choosing a Service Type

A service can be a socket, pool, or launch service. The features, advantages, and disadvantages of each of these service types is discussed below.

Socket Services

Overview of Socket Services

Socket services consist of one or more Application Servers that run continuously, servicing client requests. Socket services are generally started whenever a machine is restarted (either manually or by an operating environment mechanism for starting processes at boot or login time). The service usually runs until the machine is shut down. Socket services are relatively simple to configure and manage and are adequate for most applications.

Advantages

  • Socket services are supported on all SAS/IntrNet platforms. Other service types are not supported everywhere.
  • The server is already running by the time a client request appears, so clients do not have to wait for a server to start.
  • The administrator has explicit control of resources allocated to the service: the administrator can control how many servers are run on each system and which resources are allocated to each server.
  • Increasing load can be handled by adding more servers to the service.

Disadvantages

  • Servers must be started and stopped manually or by the operating system. No automated start-up and shutdown service is provided by SAS/IntrNet software.
  • No dynamic scaling to meet increasing loads is provided. A fixed number of servers are available to handle all client requests. A few long-running requests can slow the entire service for all clients.

Pool Services

Overview of Pool Services

Pool services consist of a pool of Application Servers shared by clients. Based on system loading the servers are started and stopped by the Application Load Manager. Numerous options are provided to fine-tune the operation of a pool service. Pool services combine some of the advantages of socket and launch services.

Advantages

  • Servers are started as needed. If all servers in the service are busy, the Load Manager can start an additional server.
  • Servers can be reused by new clients once they are started. A started server remains in the pool until an idle time-out is reached and the server is stopped.
  • Unlike launch services, pool services can be on a different system than the Web server and can be distributed across multiple server systems.
  • Using the SAS Spawner, servers can be started under specific user names to control access to system resources.

Disadvantages

  • Installation and configuration are more complex for pool services. The Application Load Manager must be installed. The SAS Spawner must be installed in some cases.
  • Client requests might have to wait for a new server to start, although this is typically no worse (and could be better) than waiting for currently executing requests to complete in a socket service.

Launch Services

Overview of Launch Services

A launch service starts a new Application Server for each client request. An existing server is reused only for applications that use sessions or the _TMPCAT catalog for IDS output. Most of the features of launch services are better provided by pool services. Launch services are not generally recommended for new installations.

Advantages

  • Server start-up is automatic for each request. Once the launch service is configured, little or no additional administration is necessary.
  • Requests run in a separate server, so a long-running request does not block access to the service for other clients.
  • Many requests can run in parallel, assuming that the system can support the load.
  • Ill-behaved applications that "crash" or "hang" a server do not affect other client requests.

Disadvantages

  • Launch services are started by the Application Broker and must run on the same system as the Web server.
  • Each new request incurs the resource overhead and delay of starting a new server session.
  • Launch services are not suitable for high user loads. There are no settable limits on the server load. The service attempts to start a new server for each new client. In an extreme case, 200 simultaneous users could cause 200 servers to be started, likely causing extreme "memory thrashing" and very slow response for all users. Most Web servers have limits on the number of simultaneous CGI requests that could help to control this problem.
  • Each launch service request must incur the additional time for starting a SAS session.
  • Launch services are not supported on z/OS.
  • Launched servers can be difficult to shut down. A launched server that creates a session or _TMPCAT catalog continues running until an idle time-out is reached. These servers cannot be shut down other than by interrupting the server process.