Administrator's Guide
CHAPTER 11
This chapter describes how to use the SMC to manage server parameters that affect the overall performance and efficient operation of your system. This chapter contains sections on:
To improve performance, you can use the SMC to set buffer sizes as well as server timeout parameters.
To set performance parameters:
|
Field |
Description |
|---|---|
|
Buffering reply size |
The size of the packet (in bytes) in which larger replies are gathered, copied, and sent back to the client. Setting this to a larger size might provide better performance—but it is best to limit the size to 8KB or 16KB, depending on available server physical memory and the number of client connections. |
|
Session timeout |
The time after which the server will terminate a session with a client after the client goes idle. The default value is five minutes. The session timeout value affects how long session object variables are maintained. The longer the timeout, the longer the memory used for a session will be consumed by the server. In deployed applications that do not use session objects, you probably want to use a short session timeout—but you probably do not want to reduce this value below four minutes. |
|
Timeout on server request |
The maximum total server-side time for processing a client request, from the instant the request is received until the reply is sent back. This allows the server to time out in the event of a persistent problem. You should set this value to be substantially longer than the longest expected server response time. |
|
Servlet background thread pool size |
Set this value only when you have deployed an exteNd Director application containing portlets. When set to a number greater than 0, specifies the number of threads that the portlet container can allocate to render portlets in parallel. |
|
Keep alive enabled |
When checked client connections can be reused for additional client requests to the server. The server uses an HTTP(s) listener that accepts client requests via the TCP/IP protocol. The server is configured to have a certain number of threads that handle the client TCP/IP connections (see Managing client connections). |
To activate the new setting(s), click the Restart (server) button.
This section describes how a client connection is established on the server, and how you can modify connection parameters to improve performance.
NOTE: Client connections are not the same as database connections. Database connections are described in Managing database connections.
When a client first connects with the server through HTTP, the server establishes the connection by allocating a thread (if available) from the connection pool.
The thread is a lightweight background process that:
Executes the HTTP request by hooking up to the appropriate server components and passing the result back to the client
The thread is associated with the client connection until either the client or the server closes it. The server will close the connection according to the settable connection parameters. When the connection is closed, the thread is returned to the client connection pool.
The session is an object on the server that does the following:
Stores information about the client (such as user ID, login, and hostname).
Stores the application data included programmatically in the client's session object (such as in a shopping cart application, which needs to store purchases and other information for each client along the way).
Remains alive for a specified time (session timeout period) after all threads have been returned to the pool. (In certain cases there can be more than one client thread associated with a session.) This allows the client to reconnect to the session within the specified time. The default timeout is five minutes. Once a session object has been deleted by the server, its contents are gone.
The following diagram shows a client connection with the server session and its associated thread:
The application server imposes a limit on the total number of allowable client connections (threads). Within this allowance, you can modify connection parameters in order to manage the server load in your production environment. The server defines client connections in terms of individual connection states and overall loads.
Each client connection (thread) exists in one of the following states:
Active, if it is connected and in use—and a request is in progress
Idle, if it is connected and in use—but no request is in progress on the connection
Once a thread has been idle for the session timeout period, the application server closes the connection and returns the thread to the connection pool. (You can configure the timeout period. See Setting performance parameters.)
A thread typically has the following life cycle:
The server has two load levels: light and busy. It behaves differently when requests for new connections are made, depending on its load level.
How the application server operates based on load levels Here is what happens when the server receives a request for a new connection:
The application server responds based on its load level:
|
Load level |
What the application server does |
|---|---|
|
Light |
The new request is allocated a free thread. When an active connection goes idle, it is kept open until it times out. |
|
Busy |
The server closes older idle connections (enough to bring the server to the light load level if possible), returning the threads to the connection pool, then allocates a free thread to the new request. If there are no idle connections (that is, all the allowable number of connections are active), the new request is refused—unless you configure the server to allow a dynamically allocated client connection (described in Setting the connection parameters). |
Specifying how the load level is determined You can specify how the server determines whether the load is light or busy using the SMC. In the descriptions that follow, the terms in bold refer to the label for the properties in the SMC:
Maximum number of client connections. Determines the total number of allowable client connections.
Idle client connection reserve. Determines the server load level:
You can set the connection parameters in the SMC.
To set client connection parameters:
The application server uses server-side caching for various purposes, including resource naming and attribute information. The application server also stores (or caches) the contents of file resources in memory or on disk. Caching is mostly invisible to users except that it affects performance.
There are two separate caches for every application server:
|
Cache |
Description |
|---|---|
|
Memory cache |
This cache is held completely in memory and is intended for holding smaller files |
|
Disk cache |
This cache is on disk and is intended for larger files |
Each cache has two settings you can configure:
You can also specify the directory used for disk caching.
The application server uses the most appropriate cache for each file based on the file's size. Small files are stored in the memory cache, and larger files are stored in the disk cache. Very large files are not cached at all. The server uses an LRU (least recently used) algorithm within each cache, throwing out old (not recently used) files when the cache becomes full.
|
Field |
Description |
|---|---|
|
Content Cache Enabled |
Enables or disables the content cache. If unchecked, all content caching is turned off. Caching of frequently requested file resources will improve the response time for these resources. Turn off only for debugging purposes. |
|
Maximum size of the disk cache |
The maximum size of the disk cache, in bytes. The total size of all files in the cache is always less than or equal to this. If set to 0, the disk cache is disabled. In general, make this cache large enough to store the remainder of frequently used files after you have determined the in-memory cache size (see the description of Maximum size of the in-memory cache below). |
|
Maximum size of any file that will be cached in the disk cache |
The maximum size of any file that is cached in the disk cache, in bytes. Files less than or equal to this size but too large for the in-memory cache are cached in the disk cache. Files greater than this size are not cached. |
|
Maximum size of the in-memory cache |
The maximum size of the in-memory cache, in bytes. The total size of all files in the cache is always less than or equal to this. If set to 0, the in-memory cache is effectively disabled. In general, make this size as large as possible without causing excessive paging activity on your system. |
|
Maximum size of any file that will be cached in the in-memory cache |
The maximum size of any file that is cached in the in-memory cache, in bytes. Files less than or equal to this size will be cached in the in-memory cache. |
|
Directory for disk cache entries |
The directory in which the disk cache entries are stored. By default, this is a subdirectory of the application server's installation directory. The server tries to create this directory if it doesn't exist. The server also tries to clear all the cache files from this directory when it starts up. (You might want to have a directory that is dedicated to the cache.) If the server cannot find or create this directory, the disk cache is disabled. |
This section contains the following topics:
The application server handles all connections between a J2EE application and a data source via a connection pool. The connections in the connection pool are typically TCP/IP connections, established between the application server and the data source through JDBC or a resource adapter archive (RAR).
Most database or enterprise information system (EIS) servers place a limit on the number of connections that can be open simultaneously. You can use the SMC to set the minimum (initial) and maximum number of connections used by the application server for each data source.
For maximum performance, the maximum number of open data source connections you set will normally equal the maximum number of users who will be simultaneously querying or updating the data source.
Setting a maximum that is too small will result in degraded performance: if a client attempts to access the data source when all connections are in use, the client will be blocked until an in-progress query or update is completed. You may want to experiment with different maximum settings to optimize your server performance.
If other applications will be establishing connections to the data source server independently of the application server, you may need to reduce the maximum number of open application server connections to make sure data source connections are available for all processes that require access to the data source.
Consult your DBMS or EIS documentation and make sure your data source has been configured to accept the number of client connections specified in the SMC, taking into account other applications that might be accessing the data source.
You can use the SMC's Pools tab to manage both JDBC and Connector connection pools, including:
You specify these values for each individual connection pool.
To update connection pool settings:
Select either Connector or JDBC to display the available connection pools.
Highlight the connection pool whose connection values you want to modify, and choose Edit.
The JDBC Edit Connection Pool Wizard displays.
You can review various settings for the connection pool, but you can update only the minimum and maximum connection values and the connection pool timeout values.
Choose Next to proceed through the wizard until you reach the panel that displays the minimum and maximum connection values shown here:
This section contains the following topics:
The application server handles all connections between a client and a deployment database. Each database connection is typically a TCP/IP connection, established between the application server and the database server through JDBC.
Most database servers place a limit on the number of database connections that can be open simultaneously. You can use the SMC to set the minimum (initial) and maximum number of connections used by the application server for each database.
The maximum number of open deployment database connections you set will normally equal the maximum number of users who will be simultaneously querying or updating the database.
Setting a maximum that is too small will result in degraded performance: if a client attempts to access the database when all connections are in use, the client will be blocked until an in-progress query or update is completed. You may want to experiment with different maximum settings to optimize your server performance.
If other database users will be establishing connections to the database server independently of the application server, you may need to reduce the maximum number of open connections. This ensures that database connections are available for non–application server users.
You should consult your DBMS documentation and make sure your database has been configured to accept the number of client connections specified in the SMC, taking into account other applications that may be accessing the database:
You can set the default maximum and minimum number of database connections, as well as the number of connections for specific databases. You do this on the Databases panel in the SMC.
You can set the default minimum and maximum number of database connections. These values are used by:
All databases currently on the server that are using the default minimum or maximum number of connections (databases whose minimum or maximum number of connections have not been changed from the default)
NOTE: To override the defaults for a specific database, see Setting the number of connections for a specific database.
To set the default maximum and minimum number of database connections:
Edit the fields at the top of the panel as needed.
|
Field |
Description |
|---|---|
|
Min # of database connections (Applies to all databases) |
The default minimum number of connections for a database. The application server will immediately establish this many connections when it is started and keep them open as long as the server is running. NOTE: If the database crashes and then restarts, the application server will drop the old connections and reestablish new ones as needed. It will not immediately establish what had been specified as the minimum number of connections. |
|
Max # of database connections (Applies to all databases) |
The default maximum number of connections for a database. The application server will open connections on demand up to this number. Make sure the maximum number of open connections is less than or equal to the total number allowed by the database server; otherwise, the application server will get errors from the database server when it attempts to open a connection.
|
You can reset the default minimum and maximum number of connections. This applies to all databases on the server.
Click Reset next to Min # or Max # of database connections at the top of the Databases panel.
The default minimum or maximum number of connections is reset, and all databases on the server are reset to use the new default values.
You can override the default numbers of database connections for a specific database.
To override the default minimum/maximum connections for a specific database:
Select the database you want to configure from the list box (under Database settings):
Set the minimum and maximum number of database connections for the selected database by editing the fields below the database name:
|
Field |
Description |
|---|---|
|
Minimum Connections |
The application server will immediately establish this many connections when it is started and keep them open as long as the server is running. Setting a value here overrides the default value. NOTE: If the database crashes and then restarts, the application server will drop the old connections and reestablish new ones as needed. It will not immediately establish what had been specified as the minimum number of connections. |
|
Maximum Connections |
The application server will open additional connections on demand up to this number. Setting a value here overrides the default value. Make sure the maximum number of open connections is less than or equal to the total number allowed by the database server; otherwise, the application server will get errors from the database server when it attempts to open a connection.
|
You can reset the minimum or maximum number of connections for a specific database to be the default values.
To restore minimum/maximum connections to the defaults:
Select the database you want to configure from the list box.
Click Reset next to Minimum Connections or Maximum Connections for the selected database:
The minimum or maximum number of connections is reset to be the default value (shown at the top of the panel).
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...
For more information, see 
