Chapter 2: Server Tuning  Java virtual machine tuning

Chapter 2: Server Tuning

General server tuning

These settings affect all applications.

Thread settings

The server threading properties affect the number of clients that can be served simultaneously and the memory used by each executing thread.

Number of threads

EAServer uses thread pooling rather than a thread-per-client model. Thread pooling allows more clients to connect than threads. Threads are created at server start-up, up to a specified maximum number. EAServer maintains separate thread pools for processing HTTP requests, IIOP requests, and internal processes that are not driven by client requests (services, garbage collection, and so forth). If the thread pools are too small, the server refuses client requests. If the size is too large, memory is wasted.

You can configure these properties to size thread pools:


EAServer Manager location

Full name

HTTP threads

Server Properties/HTTP Config, Maximum Threads

IIOP threads

Server Properties/Resources, Max Number Client Sessions

Maximum threads

Server Properties/Resources, Max Number Threads

Determining HTTP thread requirements

To determine how many HTTP threads are required, check the request pattern in the httpstat.dat file for indications of a heavily loaded server. Adjust the maximum thread setting as necessary. Ideally, this setting should be 10 – 20% more than the number of simultaneous HTTP requests that you expect to handle. (The additional threads accommodate the use of threads in Web browsers to submit simultaneous requests for images and text). A value that is too low can increase HTTP response time by causing requests to block while waiting for a thread. A value that is too high wastes available threads that could be used for other purposes.

Determining IIOP thread requirements

The number of IIOP threads must be greater than or equal to the maximum number of IIOP clients that you expect. These clients include:

Determining the required maximum threads setting

The rule for setting the maximum threads property is:

max threads = HTTP threads + IIOP threads + extra threads

The extra threads include those required to run internal processes that are not driven by client requests, including:

Typically, 50 is a sufficient number of extra threads. You may need more if you increase the number or size of the thread pools used by the message service, you run additional service components, or if you use the thread manager. You may get by with less if you do not use these features.

Thread stack size

In EAServer, the thread stack size property determines the amount of memory reserved for the call stack associated with each thread. The stack size must be sufficient to allow for nested intercomponent calls. However, if the stack size is too large, memory is wasted.

The default stack size is 256K on UNIX and on 32-bit Windows operating systems. This is appropriate for almost all situations, and provides adequate reserve memory for the largest case loads that have been tested by Sybase engineering and customers.

For production servers that see heavy use from large numbers of clients, you may want to decrease the stack size from the default value. Doing so can make the per-thread stack memory available for other uses. However, you must first run load tests on a test server to ensure that the stack size is adequate for the components running on the server. If the stack size is too small, client requests may fail with thread stack overflow errors, which are recorded in the server log.

Sybase recommends that you do not reduce the stack size if you run:

For information on setting the stack size, see “Configuring server stack size” in the EAServer System Administration Guide.

You can also configure the stack size for Java threads, as described in “JVM memory allocation parameters”.

Solaris Java thread model

On Solaris 2.8 systems, specify the -altthrdlib option to when starting the server. This option causes EAServer to run with the alternate JDK thread library that uses one-to-one mapping between kernel threads and Java threads. This threading model can yield better performance and reliability than the default many-to-many threading model.

On Solaris 2.9 and later Solaris versions, you do not need to specify this option because the Java virtual machine defaults to one-to-one thread mapping. For more information on Java thread models, see the Sun Java Threading documentation.

Flow control

When the server is very busy with many client connections, client request threads may repeatedly conflict with each other for access to low-level system resources. Flow control provides a coarser level of granularity for synchronizing access to system resources by request threads. When enabled, flow control can improve performance by replacing multiple, serial choke points in the request processing sequence with a single choke point.

NoteAlternatives to flow control As an alternative to configuring flow control for network listeners, you can configure response-time threshold monitoring for your application components or network listeners. For more information, see Chapter 9, “Using the Performance Monitor.”

Flow control is enabled separately for HTTP and IIOP clients, by setting these properties on the Advanced tab in the Server Properties dialog box:

Debug and trace settings

While useful for diagnosing configuration or code problems, debug and trace properties can reduce application performance when data is logged needlessly. Disable any debug or tracing properties unless you are actively diagnosing a related problem. You can easily disable all settings with the tuning wizard described in “The performance tuning wizard”.

Copyright © 2005. Sybase Inc. All rights reserved. Java virtual machine tuning