These settings affect all applications.
The server threading properties affect the number of clients that can be served simultaneously and the memory used by each executing thread.
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:
Property |
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 |
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.
The number of IIOP threads must be greater than or equal to the maximum number of IIOP clients that you expect. These clients include:
Standalone Java, C++, PowerBuilder, or ActiveX clients
EAServer Manager and other administrative or developer connections
Web clients that run Java applets
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:
The message service. The number of threads required can be configured in thread pool properties.
Any other service components installed in the server. Allow one thread per service, or more if you configure a service to run in multiple threads.
Components for which the Instances/Bind Thread option is enabled (that is, the com.sybase.jaguar.component.bind.thread property is set to true). Add one extra thread per component instance.
The thread manager, if you use it in your application.
The garbage collector.
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.
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:
Components that call third-party DLLs or shared libraries
Java components that call native classes (including JDBC drivers that call out to native libraries)
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”.
On Solaris 2.8 systems, specify the -altthrdlib option to serverstart.sh 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.
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.
Alternatives 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:
com.sybase.jaguar.server.flowcontrol.http enables flow control for HTTP client threads. The default is false, which disables flow control. Set the value to true to enable flow control for HTTP client requests.
com.sybase.jaguar.server.flowcontrol.iiop enables flow control for IIOP client threads. The default is false, which disables flow control. Set the value to true to enable flow control for IIOP client requests.
WARNING! In some scenarios, IIOP client threads may deadlock when IIOP flow control is enabled. Deadlock can happen when using client demarcated transactions, in stateful component instances that lock shared resources, and other cases where locks may be held across subsequent client requests. Do not enable IIOP flow control in production servers without first load testing your applications with scenarios that reflect peak production loads.
com.sybase.jaguar.server.flowcontrol.maxexethreads specifies the maximum number of threads that can concurrently execute code that is governed by flow control. The default is the value of the com.sybase.jaguar.server.maxthreads property (Resources/Maximum Threads in the Server Properties dialog box), which means all threads can proceed. Tune this number to get the best performance under peak stress conditions. Values between 15 and 30 are a good starting point. To tune the setting, monitor response time at peak load conditions, and raise or lower the value to find the setting that results in the best response time.
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. |
|
|