Sizing and Memory Settings for Sage X3 Web Server (Syracuse):

Recommendations
The Sage X3 web server architecture is based on node.js instances that are load balanced. Each node.js
process can manage pages for several users.

The Syracuse load balancer distributes user sessions over the different node.js processes. The
distribution is based on an algorithm that considers the response time and occupation rate (number of
sessions) of every node.js process.

The load balancer will also check their memory consumption, will stop assigning new sessions to a
process if necessary (“Restricted mode”), will create new processes to supplement restricted ones, and
will even terminate a process if the memory consumption and/or the response time exceeds some
parameter values that can be fine-tuned.

It is critical to size the number of nodes and to tune their CPU and memory consumption to get the best
performance. node.js is a standard framework that works in asynchronous mode. It is therefore difficult
to accurately and conclusively estimate the number of node.js processes and to size them for a
customer instance without extensive analysis.

The sizing requirement differs according to the type of page and X3 functions the users run. The heaviest
consumption is encountered with classic pages containing grids with a large number of lines (over 1000).

The guidelines in this document are a starting point but should be tuned and modified on site according
to observation, if the result is not optimal.

The configuration of node.js is based on three elements:

• Number of node.js child processes: The number of node.js processes is set-up in the host
administration page (Administration menu > Administration > Servers > Hosts)
• Memory sizing: Memory sizing for each node.js process is defined in a configuration file
called nodelocal.js, located in ..\Syracuse\bin in the Syracuse installation directory).
• Time-out settings: The time-out conditions on node.js processes, also defined in
nodelocal.js
Number of node.js Processes
The number of Node processes depends on the maximum number of session requests during peak
activity.

You can use a set of simple rules to initially size a Sage X3 Syracuse (Web) server:

• For normal usage, a node.js process can serve up to about 25 typical interactive user sessions. If
some or all those sessions have a high activity level this number should be lowered (see below
for examples of high activity levels).
• A session is a single browser tab running a Classic Page function, or the set of tabs opened by a
user running functions in Syracuse mode.
• The activity Level of a session means the actual operations performed by a session. As an
example, if there are 50 users who perform occasional entry of small sales orders or supplier
invoices, or who occasionally perform small enquiries, but whose sessions are relatively inactive
most of the time, then it might be possible to serve them all through a couple of node.js
processes. Inversely, if they perform heavy operations intensively, such as creating hundreds of
sales order lines per minute or using large enquiries with thousands of lines, then you need to
spread the sessions over more node.js processes.
• A single dedicated logical processor (CPU core) can run 2 to 4 node.js processes (depending on
their activity rate).
• The rule above also applies to node.js processes that are dedicated to Web Services, but in that
case memory consumption is normally lower because Web Service sessions are usually stateless.

The number of node.js processes can be set up through the Administration menu: Administration >
Servers > Hosts, mainly through the Number of Child Processes setting. You do not need to restart the
server when increasing the number of Child Processes, but when decreasing them you need to make
sure you are the only user connected to the application.

Some recommendations can be given to the end users to reduce memory and CPU pressure on the
node.js processes:

• Please note that all the tabs opened in the same browser of a user are assigned to a single
node.js process because they belong to the same session. If your tabs contain large classic
screens with lots of lines, it is preferable to limit the number of simultaneous browser tabs to
avoid memory over-consumption for a single node.
• The memory associated to classic pages is only released when the function is closed. Make sure
the browser tabs are closed when not needed anymore.
• If you really need to open several pages with huge Classic page grids, on each, you can use
several browsers (chrome and firefox for instance) to distribute the sessions on two different
node processes.
Sizing of node.js Processes
A default Syracuse installation has default sizing settings that define the memory consumption of each
node.js process, but you can modify them and also use advanced parameters defined in the nodelocal.js
configuration file.

The configuration file is located on the Syracuse Server (..\Syracuse\bin\nodelocal.js) and contains
default parameters settings. The nodelocal.js file is never modified during an update and must always be
set up manually. The modification will only be effective when you restart your Syracuse Server.

Warning: It is recommended you back-up the file before any modification. Incorrect JSON syntaxes in
nodelocal.js will prevent the Syracuse server from starting.

The default nodelocal.js file supplied at installation does not contain any of the advanced sizing
parameters but experience shows that it might be necessary to change default values to cover most
heavy activity classic page users. The table below lists the settings and their recommended values.

▪ memoryThreshold1: Defines the memory limit (in MB) for the heap memory beyond which a
node.js process will be placed in restricted mode, i.e. it will not accept any new connections.
This value can be extended up to the size given by max_old_space_size, see below. When a
node.js process is placed in restricted mode, it stops being part of the load balancing group and
another process is created to take its place. The current (restricted) process continues to handle
its current sessions normally but will not accept any new connection. The new process (that will
show in the process list as “no_cleanup_Nx”) runs just like a normal node.js process.
▪ memoryThreshold2: defines the memory consumption limit for the heap memory (in MB) for a
node.js process. When the memory consumed exceeds that value, the load balancer will
terminate the node.js process. This value must always be higher than memoryThreshold1.
The no_cleanup_Nx node is also terminated when it exceeds memoryThreshold1. Note that the
memory really consumed by a node can exceed this parameter, because only the heap memory is
concerned. For example, if memoryThreshold2 is equal to 8,000 the node process will terminate
only if the total memory exceeds (approximately) 9,500 MB.
▪ maxRestrictedChildren: Maximum number of node processes in restricted mode for each
“native” node process.
▪ max_old_space_size: This is the maximum memory allocation possible for the “old space” of a
node process, in MB. The “old space” is the section of node’s memory where expired memory
objects are stored. This parameter must always be higher than memoryThreshold1 and
memoryThreshold2. Giving a higher value to this parameter has an impact on the garbage
collection and makes the node process slightly faster.
▪ childPingStatusTimeout: When a child process takes longer than the number of milliseconds
specified here to respond to the load balancer’s ping, it is placed in restricted mode.
▪ childMaxTimeoutDelay: When a child process in restricted mode has not responded to any load
balancer ping during the number of minutes specified here, the process is killed.
The recommended values for those advanced parameters are as follows:

Value recommended for Value recommended with large

normal/medium usage classic screens (Inquiries with more
(Inquiries < 1000 lines , no large Excel than 1000 lines, large Excel exports,
exports) multiple tabs with large screens…)

memoryThreshold1 2500 MB 4000 MB

memoryThreshold2 3000 MB 5000 MB

childPingStatusTimeout 120 000 ms

ChildMaxTimeoutDelay 30 min

max_old_space_size 8192 MB

Depends on the number of node processes :

maxRestrictedChildren ▪ 2 if your architecture has 5 children processes or less
▪ 1 if you have more than 5 children processes
Nodelocal.js example
Here is an extract of a configuration that can be adapted:
39 "searchEngine": {
40 "hostname": "mysearchserver",
41 "port": 9600
42 },
43 "x3fusion": {
44 "records": {
45 "dumpPath": "C:\\Sage\\SAFEX3\\MYSYRSERV/Syracuse/cache/_cvg___USERNAME__"
46 },
47 },
48 "session": {
49 "timeout": 20,
50 "checkInterval": 60,
51 "auth": "basic"
52 },
53 "nanny": {
54 // Number of Nodes in restricted mode before killing the next Node turning in Restricted Mode:
55 // DefaultValue = 10; in most of the time, 10 nodes are too much and allocate too much memory
56 "maxRestrictedChildren": 2,
57 // try to connect child processes every 'childPingStatusPolling' milliseconds. Load balancer will measure the response
58 // time and consider this for load balancing. This is a sliding mean, it is computed as follows:
59 // the newest value will be considered by (100-'childSlidingMean') percent, the previous computed value
60 // by 'childSlidingMean' percent. When a child process takes longer than 'childPingStatusTimeout' milliseconds for
61 // the ping response, it will be turned into restricted mode.
62
63 // Default value: 60000 (milliseconds)
64 "childPingStatusPolling": 60000,
65 // Default value: 20 (pourcents)
66 "childSlidingMean": 20,
67
68 // Default value: 30000 (milliseconds)
69 "childPingStatusTimeout": 120000,
70
71 // Max delay for a child to stay in a consecutive timeout state. If this period of time is exceeded, the process is killed.
72 // Default value: 30 (minutes)
73 "childMaxTimeoutDelay": 30
74
75 // waiting time (milliseconds) during load balancing to obtain results of other processes
76 // Default value: 600
77 "balancingWaitTime": 600
78 },
79 "system”: {
80 // Load balancer will not assign new sessions anymore when the heap usage exceeds this value (in MB)
81 "memoryThreshold1": 2500
82 // Process will be killed during load balancer ping operation when the heap usage exceeds this value (in MB)
83 "memoryThreshold2": 3000
84 },
85 "hosting": {
86 // node.js options – could be greater than 8192 (16384 for example if the server has enough memory…)
87 "nodeOptions": "--max_old_space_size=8192"
88 }
89 }
Server Resources
The total memory and CPU capacity on the Syracuse server must be tailored to your settings, of course.
Total memory must be able to accommodate all node processes at their peak usage, and also the
additional “no_cleanup” node processes that are allowed by maxRestrictedChildren, which must be
taken into account. The maximum memory consumption of a node is defined by memoryThreshold2.

In addition, you must consider the operating system and any other applications running on that
machine. Make sure you have enough memory available! Also make sure you look at appropriate swap
space on the server's disks.

The total number of cores is calculated similarly based on the guidelines in this document. Also make
sure you have enough physical cores, proper socket distribution and the proper power management
settings (set to 'Performance', and not 'Balanced') to account for the number of vCPUs if you are running
a virtualized environment.

Memory Consumption Examples

Memory consumed by a Sage X3 connection is directly linked to the activity of that session. As an
example, running a large classic inquiry or requester (a grid screen) with 10 000 lines displayed on
screen will cause the related node.js process to typically consume several hundred Megabytes holding
the full data structure. Syracuse pages do not cause as much memory consumption as paging/caching is
used natively. Here are a few typical examples as an illustration:

Session's node.js
Sage X3 Function Display
memory consumption

Account Inquiry (CONSCPT): 10 000 lines 500 lines per page, 20 pages ~600MB

Manual Matching (LETTRAGE): 30 000 lines 15 lines per page, 2000 pages ~950Mb

Manual Matching (LETTRAGE): 30 000 lines 500 lines per page, 20 pages ~850MB