Performance tuning your Sage X3 system: Runtime

2 minute read time.

Updated: 03 August 2023

Back to Index

Please note this document and all other documents it links to are living documents so will evolve over time as new things are discovered, new functionality is provided, best practises adjusted and/or when I get time to add content; so please make sure you come back and visit this source document often.

Contents

Performance tuning your Sage X3 system: Runtime

Introduction

General blogs, KB articles, etc.

Introduction

Any performance issue in a Classic page could be considered a runtime issue, however in this section I am focussing on the technology component in isolation and will cover anything else in the “X3 considerations” section.    This leaves little to be discussed here, however are important topics.

Runtime architecture

Whether to use multiple Application Process servers or not is not only down to likely peak load, but also how many user timezones are needed.    There may also be some specific processing requirements, such as directing particular load types to particular runtime servers (using Runtime tags). 

When using multiple runtimes Sage recommend using the application cluster mode, rather than the previous additional process server architecture.  This recommendation is discussed in the Architecture and system requirements and in more detail in the online help Application Cluster Architecture.  This preference is discussed in the referenced documents, but from performance point of view will provide a more consistent performance as all Runtimes have access directly to the X3 folders file system.

Network latency between X3 Application/Runtime server(s) and the Database server

Sage recommends the Application server, Process servers and Database server should be using minimum of 10Gbps network and on the same switch if possible, or same sub-net.   Latency is critical because X3 uses cursors and goes back and forth a lot.   Ideally the expected latency should be < 0.4 milliseconds (ms)  If database is on a separate server from the Process server, there is an expected small performance hit due to this network traffic.

The simplest way to check the latency is to use the “ping” command in both directions between the Sage X3 Apps server and the database server.  There are other free tools you can use which may be more sophisticated, for example PsPing (Sysinternals) or hrPing.  For example, I would probably use the following ping command for testing latency if no other tools were available:

ping -n 3 -f -l 1472 %REMOTE_HOSTNAME%

Network tuning

On all X3 Runtime and Syracuse servers the following settings are recommended for best performance and stability.

This is discussed in KB article “Microsoft Windows timeout session allocation (KeepAlive) configuration guidelines for Sage X3 Environments

Anti-Virus

Can sometimes interfere with performance.  Check the Anti-Virus is configured as per Sage recommendations.  Also check CPU time for the Anti-Virus binary in Windows Task Manager to see if it’s chewing up CPU (high CPU time may indicate its doing a lot of work… but doing what exactly?)

Sage recommendations for Anti-Virus are discussed in Architecture and system requirements.

General blogs, KB articles, etc.

Architecture and system requirements (Online help)

Application Cluster Architecture (Online help)

V12 prerequisites (Online help)

Microsoft Windows timeout session allocation (KeepAlive) configuration guidelines for Sage X3 Environments (KB article)

Back to Index