HP Integrity NonStop J-Series - Manual (Page 249)

NSJSP is configured with SessionBasedLoadBalancing turned ON
•
The value of Numstatic must be [(Peak Load)/(Max load one instance of NSJSP
can handle)]
.
•
The value of Maxservers must be [(Peak Load)/(Max load one instance of
NSJSP can handle)]
. This ensures that no dynamic process is created, so that the session
object is not lost when there are numerous file system calls.
•
The value of Maxlinks must be set to the peak load that one instance of NSJSP is expected
to handle.
•
Arriving at a definite value for TANDEM_RECEIVE_DEPTH is difficult when NSJSP is configured
with SessionBasedLoadBalancing turned ON. Deciding an optimum value for
TANDEM_RECEIVE_DEPTH
requires a good understanding of the application. The following
example provides an insight into making this decision.
•
Maximum number of connector threads, maxThreads must be equal to the value of
TANDEM_RECEIVE_DEPTH
.
For example:
In this example, it is evident how a single instance of NSJSP, although having Maxlinks set to
25, can serve all the 100 requests.
Because SessionBasedLoadBalancing is turned ON, all messages between HTTPD and
NSJSP
flow through TS/MP and file system calls. The number of simultaneous messages that can
be delivered to an instance of NSJSP is determined by the value of Maxlinks; set the value of
Maxlinks
to 25.
With Maxlinks set to 25, a single instance of NSJSP can handle 25 concurrent requests through
TS/MP, all being the first requests of web dialogs. The first call on a web dialog is always delivered
to NSJSP through TS/MP and there will not be any file system call. Once the 25 requests are
serviced, subsequent requests on those 25 web dialogs are delivered to NSJSP through file system
I/O operations.
At this stage, all 25 links to the NSJSP instance are free to process more incoming requests delivered
through TS/MP. Therefore, the NSJSP instance should now be able to handle 25 more concurrent
requests all being the first requests of web dialogs. After the 25 requests are processed, the
subsequent requests on these new connections arrive at NSJSP through file system I/O. At this
stage, NSJSP could be handling up to 50 concurrent requests and all these requests are delivered
through file system calls from httpd and not through TS/MP. Hence, the 25 links are free to
process new web dialogs. Therefore, a single instance of NSJSP can serve all the 100 requests.
At this point, one instance of NSJSP could be processing requests from all the possible 100
connections to the httpd processes. This means that there could be a scenario where all the 100
requests time out. Therefore, there must be enough space in the $RECEIVE file to handle (100+100)
messages. Therefore, TANDEM_RECEIVE_DEPTH must have a value of 200. The reason for setting
TANDEM_RECEIVE_DEPTH
to a value of 200 can be explained as:
To handle 100 requests, you need 100 threads. In an extreme case of all the 100 requests timing
out, you need another 100 threads to process the new incoming 100 requests because the threads
processing the timeout requests could still be busy. Therefore, the number of threads that need to
be configured is (100+100 = 200).
Configuring Java Runtime Arguments
The configurations for Java runtime arguments can be done in the <iTP WebServer Deployment
Directory>/conf/servlet.config
file on OSS. The sscaux object is configured under
the Server directive. Java runtime arguments are populated in the Arglist. Some of the important
NonStop Platform Configurations 249