Net8 Administrator's Guide
Release 8.1.6

Part Number A76933-01

Library

Product

Contents

Index

Go to previous page Go to next page

9
Configuring Multi-Threaded Server

This chapter describes how to configure multi-threaded server (MTS). It includes the following sections:

Overview

Consider an order entry system with a dedicated server architecture. A customer places an order as a clerk enters the order into the database. For most of the transaction, the clerk is on the telephone talking to the customer and the server process dedicated to the clerk's user process remains idle. The server process is not needed during most of the transaction, and the system is slower for other clerks entering orders because the idle server process is holding system resources.

The MTS architecture eliminates the need for a dedicated server process for each connection (see Figure 9-1). A dispatcher directs multiple incoming network session requests to a pool of shared server processes. An idle shared server process from a shared pool of server processes picks up a request from a common queue. This means a small number of shared servers can perform the same amount of processing as many dedicated servers. Also, since the amount of memory required for each user is relatively small, less memory and process management are required, and more users can be supported.

The advantage of MTS is that system overhead is reduced and less resources are used, allowing the number of users supported to be increased.

See Also:

"Multi-Threaded Server Model" 

Figure 9-1 MTS Architecture

See Also:

"Multi-Threaded Server Model" 

Configuring MTS with the MTS_DISPATCHERS Parameter

To enable an MTS configuration, set the MTS_DISPATCHERS parameter in the initialization parameter file.


Note:

Oracle Database Configuration Assistant enables you to configure this parameter. 


After setting this parameter, restart the instance to enable MTS configuration.

MTS_DISPATCHERS should be set in the following manner:

mts_dispatchers="(atttribute=value)"

One of the following attributes is required to enable MTS: ADDRESS (ADD or ADDR), DESCRIPTION (DES or DESC), or PROTOCOL (PRO or PROT).

Attribute  Description 

ADDRESS (ADD or ADDR) 

Specifies the network protocol address of the endpoint on which the dispatchers listen.  

DESCRIPTION (DES or DESC)  

Specifies the network description of the endpoint on which the dispatchers listen, including the network protocol address. The syntax is as follows:

(description=(address=...))
 

PROTOCOL (PRO or PROT)

 

Specifies the network protocol for which the dispatcher generates a listening endpoint. For example:

(protocol=tcp)

See Also: Appendix B for further information about protocol address syntax 

The attributes CONNECTIONS (CON or CONN), DISPATCHERS (DIS or DISP), LISTENER (LIS or LIST), MULTIPLEX (MUL or MULT), POOL, SERVICE (SER, SERV), SESSIONS (SES or SESS), and TICKS are optional:

Attribute  Description 

CONNECTIONS (CON or CONN) 

Specifies the maximum number of network connections to allow for each dispatcher

The default is operating-system specific. For example, 1024 is the default for Sun Solaris and Windows NT. 

DISPATCHERS (DIS or DISP) 

Specifies the initial number of dispatchers to start. The default is 1. 

LISTENER (LIS or LIST)  

Specifies an alias name for the listener(s) with which the PMON process registers dispatcher information. The alias should be set to a name which is resolved through a naming method.

This attribute need only be specified if the:

  • Listener is a local listener that uses a non-default address, that is, not TCP/IP, port 1521

  • Listener(s) are on other nodes

Non-default local listeners may also be specified with the LOCAL_LISTENER parameter.

Important: The listener alias must be resolved through a naming method, such as a tnsnames.ora file on the server or an Oracle Names server.

For example, if the listener alias name is listener_sales with two listening endpoints of port 1521, and the chosen naming method is the local naming method, the entry in the tnsnames.ora file would look like the following:

listener_sales= 
(description= 
   (address=(protocol=tcp)(host=sales1-server)(port= 1521))
   (address=(protocol=tcp)(host=sales2-server)(port= 1521)))
 

MULTIPLEX (MUL or MULT) 

Enables Oracle Connection Manager's connection concentration feature

If 1, ON, YES, TRUE, or BOTH is specified, then connection concentration is enabled for both incoming and outgoing network connections.

If IN is specified, the connection concentration is enabled for incoming network connections from clients.

If OUT is specified, the connection concentration is enabled for outgoing network connections.

If 0, NO, OFF, or FALSE is specified, then connection concentration is disabled for both incoming and outgoing network connections.

See Also: "Enabling Connection Concentration" 

POOL 

Enables connection pooling

If a number is specified, enables connection pooling for both incoming and outgoing network connections. The number specified is the timeout in ticks for both incoming and outgoing network connections.

If ON, YES, TRUE, or BOTH is specified, enables connection pooling for both incoming and outgoing network connections. A default timeout of 10 ticks is used for both incoming and outgoing network connections.

If IN is specified, connection pooling is enabled for incoming network connections and the default timeout of 10 ticks is used for incoming network connections. IN can also be assigned a timeout in ticks value, such as (IN=20). If the numeric value of a specified timeout is 0 or 1, then the default value of 10 ticks is used.

If OUT is specified, connection pooling is enabled for outgoing network connections and the default timeout of 10 ticks is used for outgoing network connections. OUT can also be assigned a timeout in ticks value, such as (OUT=20). If the numeric value of a specified timeout is 0 or 1, then the default value of 10 ticks is used.

If NO, OFF, or FALSE is specified, then connection pooling is disabled for both incoming and outgoing network connections.

See Also: "Enabling Connection Pooling" 

SERVICE (SER, SERV) 

Specifies the service name(s) the dispatchers register with the listeners. If not value are specified, the service names specified with the SERVICE_NAMES parameter are used.  

SESSIONS (SES or SESS)  

The maximum number of network sessions to allow for each dispatcher.

The default is operating-system specific. Most operating systems have a default of 16K. 

TICKS 

The size of a network tick in seconds. The value set is multiplied with the POOL timeout value to get the total connection pool timeout.

The default is 15 seconds. For a fast network, Oracle Corporation recommends a tick size of ~1 second. For a slow network, Oracle Corporation recommends a tick size of ~3-4 seconds.  

Setting the Initial Number of Dispatchers

The number of dispatchers started at instance startup is controlled by the DISPATCHERS attribute.


Note:

Unlike the shared servers, the number of dispatchers does not change dynamically. The number of dispatchers must be explicitly changed with the ALTER SYSTEM command. You can change the number of dispatchers in this manner up to a maximum limit specified by the MTS_MAX_DISPATCHERS parameter. See the Oracle8i Designing and Tuning for Performance for further information about this parameter. 


The appropriate number of dispatchers for each instance depends upon the performance you want from your database, the host operating system's limit on the number of connections per process, (which is operating system dependent), and the number of connections required per network protocol.

Calculating the Initial Number of Dispatchers

Once you know the number of possible connections per process for your operating system, calculate the initial number of dispatchers to create during instance startup, per network protocol, using the following formula.

number                 maximum number of concurrent sessions
of           = CEIL   (--------------------------------------------------------------------------)
dispatchers                connections per dispatcher

CEIL represents the number roundest to the next highest number.

As an example, assume that a system that has:

In this case, the DISPATCHERS attribute for TCP/IP should be set to a minimum of four dispatchers and SPX should be set to a minimum of three dispatchers:

mts_dispatchers="(protocol=tcp)(dispatchers=4)(connections=1000)"
mts_dispatchers="(protocol=spx)(dispatchers=3)(connections=1000)"

Depending on performance, you may need to adjust the number of dispatchers.

Setting Dispatcher Addresses

Example 1

To force the IP address used for the dispatchers, set the following:

mts_dispatchers="(address=(protocol=tcp)(host=144.25.16.201))
(dispatchers=2)"

This starts two dispatchers that listen on HOST=144.25.16.201. Note that Net8 dynamically selects the TCP/IP port for the dispatcher.

Example 2

To force the exact location of the dispatchers, add the PORT as follows:

mts_dispatchers="(address=(protocol=tcp)
(host=144.25.16.201)(port=5000))(dispatchers=1)"
mts_dispatchers="(address=(protocol=tcp)
(host=144.25.16.201)(port=5001))(dispatchers=1)"


Note:

You can specify multiple MTS_DISPATCHERS in the initialization file, but they must be adjacent to each other.  


Enabling Connection Pooling

Connection pooling is a resource utilization feature that enables you to reduce the number of physical network connections to a dispatcher. This is achieved by sharing or pooling a set of connections among the client processes.

To configure connection pooling, set the MTS_DISPATCHERS parameter in the initialization parameter file with the POOL attribute and the following optional attributes:

Returning to the example in "Calculating the Initial Number of Dispatchers", connection pooling can be used to allow each dispatcher 1,000 connections and 4,000 sessions for TCP/IP and 3,000 sessions for SPX. This reduces the configuration to one dispatcher for each protocol, as shown in the following:

mts_dispatchers="(protocol=tcp)(dispatchers=1)(pool=on)(tick=1) (connections=1000)(sessions=4000)"

mts_dispatchers="(protocol=spx)(dispatchers=1)(pool=on)(tick=1) 
(connections=2000)"

Allocating Resources

An Oracle8i database can be represented by multiple service names. Because of this, a pool of MTS dispatchers can be allocated exclusively for clients requesting a particular service. This way, the mission critical requests may be given more resources and, thus, in effect increase their priority.

For example, the following initialization parameter file sample shows two dispatchers. The first dispatcher services requests for clients requesting sales.us.acme.com. The other dispatcher services requests for only clients requesting adminsales.us.acme.com.

service_names=sales.us.acme.com
instance_name=sales
mts_dispatchers="(protocol=tcp)" 
mts_dispatchers="(protocol=tcp)(service=adminsales.us.acme.com)" 

Using MTS on Clients

If MTS is configured and a client connection request comes when no dispatchers are registered, the requests can be handled by a dedicated server (configured in the listener.ora file). If you want a particular client to always use a dispatcher, configure (SERVER=SHARED) in the connect data portion of the connect descriptor. For example:

sales= 
(description= 
  (address=(protocol=tcp)(host=sales-server)(port= 1521))
  (connect_data=
     (service_name=sales.us.acme.com)
     (server=shared)))

If a dispatcher is not available, the client connection request is rejected.

See Also:

"Configuring Advanced Connect Data Parameters" to set the SERVER parameter 

Overriding MTS on Clients

If the database is configured for MTS and a particular client requires a dedicated server, the client can be configured to use a dedicated server in one of the following ways:


Go to previous page Go to next page
Oracle
Copyright © 1996-2000, Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index