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

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

Miscellaneous magnus.conf Directives
226 Netscape Enterprise Server Administrator’s Guide
In the single-process design, the server receives requests from web clients to a
single process. Inside the single server process, many threads are running
which are waiting for new requests to arrive. When a request arrives, it is
handled by the thread receiving the request. Because the server is multi-
threaded, all extensions written to the server (NSAPI) must be thread-safe. This
means that if the NSAPI extension uses a global resource (like a shared
reference to a file or global variable) then the use of that resource must be
synchronized so that only one thread accesses it at a time. All plugins provided
by Netscape are thread-safe and thread-aware, providing good scalability and
concurrency. However, your legacy applications may be single-threaded. When
the server runs the application, it can only execute one at a time. This leads to
severe performance problems when put under load. Unfortunately, in the
single-process design, there is no real workaround.
In the multi-process design, the server spawns multiple server processes at
startup. Each process contains one or more threads (depending on the
configuration) which receive incoming requests. Since each process is
completely independent, each one has its own copies of global variables,
shared libraries, caches, and other resources. Using multiple processes requires
more resources from your system. Also, if you try to install an application
which requires shared state, it has to synchronize that state across multiple
processes. NSAPI provides no helper functions for implementing cross-process
synchronization.
If you are not running any NSAPI in your server, you should use the default
settings: one process and many threads. If you are running an application
which is not scalable in a threaded environment, you should use a few
processes and many threads, for example, 4 or 8 processes and 256 or 512
threads per process.
Prior to HPUX 10.30, HPUX thread support consisted of DCE threads. The
implementation of DCE threads were “user level” threads, which means that
they are schedule only in user space. Since the kernel does not know anything
about the user threads, these threads are cooperatively scheduled within the
context of a single process. This means that on multi-processor systems, all the
DCE threads will only be scheduled on one processor at a time. This prevents
MP scaling. With HPUX 10.30, HPUX introduced its first kernel based threading
model (
pthreads
). Since the kernel has knowledge of these threads, and
since the kernel is responsible for scheduling these threads, programs written to
the
pthreads
API can be scheduled on all processors in a multi-processor
system. Enterprise Server 4.0 now uses HP’s kernel-level threads.