Multi-Process Mode

You can configure the server to handle requests using multiple processes
with multiple threads in each process. This flexibility provides
optimal performance for sites using threads, and also provides backward compatibility
to sites running legacy applications that are not ready to run in a threaded
environment. Because applications on Windows generally already take advantage
of multi-thread considerations, this feature applies to UNIX and Linux platforms.

The advantage of multiple processes is that legacy applications that
are not thread-aware or thread-safe can be run more effectively in Sun Java
System Web Server. However, because all of the Sun Java System extensions
are built to support a single-process threaded environment, they might not
run in the multi-process mode. The Search plug-ins fail on startup if the
server is in multi-process mode, and if session replication is enabled, the
server will fail to start in multi-process mode.

In the multi-process mode, the server spawns multiple server processes
at startup. Depending
on the configuration, each process contains one or more threads, that
receive incoming requests. Since each process is completely independent, each
one has its own copies of global variables, caches, and other resources. Using
multiple processes requires more resources from your system. Also, if you
try to install an application that requires shared state, it has to synchronize
that state across multiple processes. NSAPI provides no helper functions for
implementing cross-process synchronization.

When you specify a MaxProcs value greater than 1, the server relies on the operating
system to distribute connections among multiple server processes (see MaxProcs (UNIX/Linux) for information about the MaxProcs directive). However, many modern operating systems do not
distribute connections evenly, particularly when there are a small number
of concurrent connections.

Because Sun
Java System Web Server cannot guarantee that load is distributed evenly among
server processes, you might encounter performance problems if you set Maximum Threads to 1 and MaxProcs greater
than 1 to accommodate a legacy application that is not thread-safe. The problem
is especially pronounced if the legacy application takes a long time to respond
to requests, for example, when the legacy application
contacts a back-end database. In this scenario, it might be preferable to use the default value
for Maximum Threads and serialize access to the legacy application using thread
pools. For more information about creating a thread pool, see thread-pool-init in Sun Java System Web Server 7.0 Update 7 Administrator’s Configuration File Reference.

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
that is not scalable in a threaded environment, you should use a few processes
and many threads, for example, 4 or 8 processes and 128 or 512 threads per
process.

MaxProcs (UNIX/Linux)

To run a UNIX or Linux server in multi-process mode, set the MaxProcs
directive to a value that is greater than 1. Multi-process mode might provide
higher scalability on multi-processor machines and improve the overall server
throughput on large systems such as the Sun FireTM T2000
server. If you set the value to less than 1, it is ignored and the default
value of 1 is used.

Use the MaxProcs directive to improve overall server throughput for
the following types of applications:

NSAPI applications that do not implement fine-grained locking

Java applications that do not require session management

Do not use the MaxProcs directive when the Sun
Java System Web Server performs session management for Java applications.

You can set the value for MaxProcs by editing the MaxProcs parameter in magnus.conf.

Note –

You will receive duplicate startup messages when running your
server in MaxProcs mode.