I received a query on some "under-documented variables" and thought that I'd share it out.
Now, I'll let you know up front that you do NOT need to change these variables or in fact, do anything with them at all.
However, if you've been wondering what they are and somehow found your way to this post, then hopefully this will tell you more than you knew before.
The NX.env file contains this section:
# NX_DOMSRVR_MAX_CLIENTS is the maximum number of clients that will
# be allowed to connect to this domsrvr. This value is also
# used in the weighting of the willingness factor when a
# client is attempting to connect to a domsrvr.
# NX_ANI_CONN_LOAD & NX_WEB_CONN_LOAD are used to balance loads between animator_nxd,
# webengine(s) and user connections. Each user connection
# represents a load value of 1. Setting NX_ANI_CONN_LOAD=10
# means that animator_nxd is running a load equivalant to
# 10 user connections and NX_DOMSRVR_MAX_CLIENTS will be
# reduced by 10 for the domsrvr the animator_nxd is connected to.
These variables are used to help overloading the domsrvr processes, by calculating an upper bound per domsrvr.
Each process has a client connection weight. In this example, the animator has a weight of "10 client connections." (I'll just call it "cc".)
This means that when the tally is done, if 3 users and 1 animator process connect to the domsrvr, then it will work out a client connection weight of:
(3 users x 1 cc/user) + (1 animator x 10 cc/animator) = 13 cc.
Now, changing the cc weight on the animator has absolutely no impact on performance at all. None.
So there is really no very good reason for changing this variable ever.
What it will do is to update the client connection count and it will flag when at 90% of the "max clients" a "SIGNIFICANT" message and at 95% an "ERROR" message.
In theory, you could track those and know when your system was approaching limits.
In practice, you want to get your scoping and performance tuning well under way before that happens.
A well tuned system won't see those messages. And we often use a "rule of thumb" that domsrvr/webengine pairs should serve between 150 - 300 users "depending on load" in any case.
That is, a single domsrvr process may serve 300 Employees concurrently fine, but may struggle with 150 Analysts if a lot of the work that they do is firing off Animated Events.
So in short, those variables do not in any way control the load on the domsrvr or animator.
Instead, they control what messages are written to the stdlog, and advise when a process use is getting close to capacity.
And finally, there is no good reason to touch them!
That is probably why these variables have been "undocumented" in the product documentation for so many years.
There are lots of undocumented variables which should not be changed - and these are some of them.
I hope that helped with someone's curiosity.