Sun Microsystems Netscape Enterprise Server, Руководство администратора

Страница: 255 / 532

Chapter 10, Configuring the Server for Performance 255
Improving Servlet Performance
threads which may be doing other processing can be suspended by the garbage
collector arbitrarily. Thread pools can be used to eliminate this side effect for
othersubsystems.
Thread Pools
Enterprise Server 4.0 allows to specify a number of configurable native thread
pools, by adding the following directives to the
obj.conf
:
Init fn="thread-pool-init" name=name_of_the_pool MaxThreads=n MinThreads=n
QueueSize=n StackSize=n
Pool must be declared before it’s used. To use the pool add
pool= name_of_the_pool
parameter to load-modules directive of the
appropriate subsystem. The older parameter
NativeThread=yes
will always
engage one default native pool, called NativePool.
In addition to configuring the native pool parameters on Windows NT using the
environmental variables beginning with “NSCP_POOL” in Enterprise Server 3.6,
the following parameters can be added to
magnus.conf
for convenience:
NativePoolMinThreads.
Default value is 1.
NativePoolMaxThreads.
Default value is 128.
NativePoolQueueSize.
Default value is unlimited.
NativePoolStackSize.
Default value is the same as the default value
for the OS.
Any of the parameters can be omitted to reflect the default behavior.
Native pool on Unix is normally not engaged, as all threads are OS-level
threads. Using native pools on Unix may introduce a small performance
overhead as they’ll require an additional context switch, however they can be
used to localize jvm.stickyAttach effect or for other purposes, such as resource
control/management or to emulate single-threaded behavior of plugins (by
setting
maxThreads=1
).
On Windows NT, however, at least the default native pool is always being used
and Enterprise Server uses fibers (user-scheduled threads) for initial request
processing. Using custom/additional pools on Windows NT will introduce no
additional overhead.