Buffer Size

You can specify the size of the send buffer (SndBufSize) and the receiving buffer (RcvBufSize) at the server’s sockets.
For more information regarding these buffers, see your UNIX/Linux documentation.

Tuning

You can set the buffer size by:

Editing the SndBufSize and RcvBufSize parameters
in magnus.conf

Setting or changing the SndBufSize and RcvBufSize values in the Magnus Editor of the Server Manager

Connection Timeout

You can specify the number of seconds the server waits for data to arrive
from the client before closing the connection by using theAcceptTimeout directive. If data does not arrive
before the timeout expires, the connection is closed. This is set to 30 seconds
by default. Under most circumstances, you won’t need to change this
setting. You can free up threads by setting this to less than the default,
but you might also disconnect users with slower connections.

Tuning

You can set AcceptTimeout by:

Editing the AcceptTimeout parameter in magnus.conf

Setting or changing the AcceptTimeout value
in the Magnus Editor of the Server Manager

CGIStub Processes (UNIX/Linux)

You can adjust the CGIStub parameters on UNIX/Linux
systems. In Sun Java System Web Server, the CGI engine creates CGIStub processes
as needed. On systems that serve a large load and rely heavily on CGI-generated
content, it is possible for the CGIStub processes to consume
all system resources. If this is happening on your server, the CGIStub processes
can be tuned to restrict how many new CGIStub processes
can be spawned, their timeout value, and the minimum number of CGIStub processes
that will be running at any given moment.

Note –

If you have an init-cgi function in the magnus.conf file
and you are running in multi-process mode, you must add LateInit
= yes to the init-cgi line.

The four directives and their defaults that can be tuned to control Cgistub are:

MinCGIStubs

MaxCGIStubs

CGIStubIdleTimeout

CGIExpirationTimeout

MinCGIStubs controls the number of processes
that are started by default. The first CGIStub process
is not started until a CGI program has been accessed. The default value is
2. If you have a init-cgi directive in the magnus.conf file, the minimum number of CGIStub processes
are spawned at startup.

MaxCGIStubs controls the maximum number of CGIStub processes the server can spawn. This is the maximum concurrent CGIStub processes in execution, not the maximum number of pending
requests. The default value shown should be adequate for most systems. Setting
this too high may actually reduce throughput. The default is 10.

CGIStubIdleTimeout causes the server to kill
any CGIStub processes that have been idle for the number
of seconds set by this directive. Once the number of processes is at MinCGIStubs, it does not kill any more processes. The default is 45.

CGIExpirationTimeout limits the maximum time
in seconds that CGI processes can run.

Tuning

You can set the CGIStub processes by:

Editing them in magnus.conf

Setting or changing their values in the Magnus Editor of the
Server Manager

Miscellaneous obj.conf Parameters

You can use some obj.conf function parameters to
improve your server’s performance, as discussed in the topics in this
section:

find-pathinfo-forward

The parameter find-pathinfo-forward for the PathCheck function find-pathinfo and the NameTrans functions pfx2dir and assign-name can help you improve your performance.
The find-pathinfo-forward parameter instructs the server
to search forward for PATH_INFO in the path after ntrans-base, instead of backward from the end
of path in the server function find-pathinfo.

Note –

The server ignores the find-pathinfo-forward parameter if the ntrans-base parameter is not set in rq-\>vars when the server function find-pathinfo is called.
By default, ntrans-base is set.

This feature can improve performance for certain URLs by doing fewer
stats in the server function find-pathinfo. On Windows,
you can also use this feature to prevent the server from changing "\" to "/"
when using the PathCheck server function find-pathinfo.

nostat

You can specify the parameter nostat in the NameTrans function assign-name to prevent the server from doing
a stat on a specified URL whenever possible. Use the following syntax:

In the previous example, the server does not stat for path /ntrans-base/nsfc and /ntrans-base/nsfc/* if ntrans-base is set. If ntrans-base is not set, the server does not stat for URLs /nsfc and /nsfc/*. By default, ntrans-base is set. The
example assumes the default PathCheck server functions
are used.

When you use nostat= virtual-path in
the assign-nameNameTrans, the server
assumes that stat on the specified virtual-path will
fail. Therefore, use nostat only when the path of the virtual-path does not exist on the system, for example, in NSAPI
plugin URLs. Using nostat on those URLs improves performance
by avoiding unnecessary stats on those URLs.

Using Quality of Service

The quality of service features allow you to limit the amount of bandwidth
and number of connections for a server instance, class of virtual servers,
or an individual virtual server. You can set these performance limits, track
them, and optionally enforce them.

Using Load Balancing

With load balancing, the amount of server traffic is divided between
two or more computers so that more work gets done in the same amount of time
and all online users will generally be served faster. Third-party plugins
can be used to provide load balancing capabilities for Sun Java System Web
Server. Contact load balancing plugin providers for information about solutions
that work with Sun Java System Web Server.

Using libloadbal

You can use the load balancing plugin libloadbal to allow your server
to execute a program when certain thread load conditions are met, so a load
distribution product on the front-end can redistribute the load.

There are two methods that you can use to trigger the load balancer
to increase or decrease load:

Standard

Base
load decisions on the number of queued requests. This is a passive approach.
By letting the queue fill up you are already delaying some requests. In this
case, you want the HighThreshold to be a low value and LowThreshold to be a high value.

Aggressive

Base
load decisions on the number of active threads in the pool. This is designed
to more tightly control the requests so that you would reduce the load before
requests get queued.

Library configuration

To enable the plugin, you must modify magnus.conf manually. This should look something
like this:

Testing

To test the load balancer, you can create an NSAPI plugin that prints
an HTML page and then calls sleep() for a period to simulate
execution time. This way you can build up a simulated load on the server and
ensure that the load balancer commands are working properly.

To configure the sample program

Add a new mime.type so
this isn't run for every request by modifying config/mime.types and adding:

type=magnus-internal/sleep exts=sleep

Create a file in your document root directory with the extension
of .sleep.

It does
not matter if anything is in this file; it is used only as a placeholder.

The argument duration tells the server how long to
sleep for each request in seconds.

Restart your server.

You should now be ready to test
the load balancer plugin. The NSAPI plugin will keep the threads busy long
enough to simulate your desired load. The load balancing plugin is tested
by retrieving the .sleep file you created earlier.