Before retiring to the background, the NSD displays a banner indicating its running configuration. It shows the TCP port number dedicated to this service, which is, by default, port number 7038.
These commands close down the NSD in an orderly manner – it gracefully terminates all open connections to InterSystems IRIS and releases all its system resources before terminating. Do not use the kill –9 command to terminate the NSD.
Starting the NSD on Alternative TCP Port
By default, the NSD listens for incoming requests on TCP port 7038. You can override this by starting the service as follows, where port_no is the TCP port number of your choice.
On startup, the NSD creates the following file:
Typically, this file contains the following lines:
In this context, the clients are the Web Gateway module contained within, or dynamically linked to, the web server and/or the Web Gateway CGI modules invoked by the server. It is, therefore, essential that this file is not deleted or moved. It is also important that the web server processes can read this file. Set the privileges accordingly, bearing in mind the UNIX® username under which your web server is operating. The NSD clients attempt to find this file in the following locations:
If the NSD is operating in a different directory, you have to move the CSPnsd.ini file to one of the locations listed.
It is inappropriate to store the NSD port number in the CSPnsd.ini file in situations in which multiple instances of the NSD are running. For Apache servers, there is a much better mechanism for communicating the TCP port number of the NSD to its clients. Specifically, set the following environment variables in the Apache configuration to indicate the address and port of the target NSD installation.
The values specified in these environment variables take precedence over any values found in the CSPnsd.ini file.
Example 1: Two Apache Virtual Hosts
To distribute the load for two Apache virtual hosts (184.108.40.206 and 220.127.116.11) between two independent NSD installations (listening on TCP port 7038 and 7039), add the following directives to the Apache configuration (httpd.conf):
SetEnv CSP_NSD_PORT 7038
SetEnv CSP_NSD_PORT 7039
Example 2: Two Web Applications
To distribute the load for two web applications (/csp1 and /csp2) between two independent NSD installations (listening on TCP port 7038 and 7039), add the following directives to the Apache configuration (httpd.conf):
SetEnv CSP_NSD_PORT 7038
SetEnv CSP_NSD_PORT 7039
Restart Apache after making changes to its configuration.
In cases where multiple instances of the NSD are running, it is recommended that the separate instances be installed in separate directories, each maintaining its own copy of the configuration and log files. The Web Gateway management pages for each instance can easily be accessed by using the NSD's internal HTTP server. For example:
Spreading the Load over Multiple NSD Processes
By default, the NSD operates in a two-process mode of operation (one parent and one child worker).
However, there are limits to the number of threads that a single UNIX® process can start. If the concurrent load of the web application is resulting in requests queuing for available threads, consider raising the number of processes used by the NSD.
- where no_processes is the number of child (or worker) processes to start.
It should be noted that there are even advantages in setting the number of child processes to one.
Under these circumstances, the NSD actually starts two processes: a parent and one child worker process. The presence of the parent processes when using the ‘–c’ directive improves the resilience of the NSD because if a fault develops in one of the worker processes the parent can replace the process. For the single, multi-threaded architecture, the NSD cannot always recover from serious internal error conditions.
State-aware connectivity (preserve mode 1) should not be used in cases where the number of worker processes exceeds one.
Granting Administrator Rights to the NSD
Administrators of the NSD (CSPnsd) component can have some control over the user (or group) permitted to start/stop this service.
In the default scenario, the CSPnsd master process ID (PID) file (CSPnsd) is created such that only the user who started the service can subsequently close it down.
Administrators can now choose, for example, to allow all users belonging to the current UNIX® group to manage the service. This is the group to which the administrating user belongs.
NSD start-up option: [-m=s]
Define the user(s) permitted to manage this service
where 's' is:
'u' for the current user (the default),
'g' for the current group,
'o' for others,
'a' for everyone (m=ugo),
This allows the current user and all others in the current user's group to manage the NSD.
When the command to stop the NSD is issued, it first tries to signal the CSPnsd parent process to shut down as before. If this is not possible due to the service having been started by a different user, a flag is written to the CSPnsd.ini file and the service gracefully closes itself down when it acknowledges this flag. This process takes up to 20 seconds to complete.