How to decide the hardware configuration for Ignition server and client?

Ignition
1

What parameters do we need to consider to decide the processor, RAM, disk space etc. for Ignition server as well as clients? Minimum system requirement for server is provided by IA but typically we recommend more considering future compatibility but customers want to understand the basis for providing certain processor or memory.

Especially customers with OT background have this query since in PLC number of inputs/outputs can help in selection of processor/module etc. Similarly, are there any factors like number of installed modules, device connections, number of concurrent clients etc. which need to be considered for server hardware selection? Can we apply similar rules for client hardware selection as well?

There may not be a formula for selection similar to PLC, but certain guidelines/thumb rules can help us in selection and also in answering customers’ doubts.

2

Ignition’s modular nature and the wide variety of performance criteria that can be applied when setting up its core makes it virtually impossible to accurately forecast gateway CPU load. At least, I’ve not seen any spreadsheet/algorithm that does so.

Fortunately, Ignition’s two-hour trial mode makes it practical to mock up an application with realistic traffic and look at the resulting load. I am among those who also recommend running the database on separate hardware (or a separate VM in a non-overcommitted hypervisor).

2 Likes
3

General advice:
Lots of cores - individual clock speed doesn’t matter nearly as much. Java, and therefore Ignition, parallelize well to multiple CPU cores. This is especially relevant if you’ll be using Perspective, because Perspective sessions have a ‘backend’ component running on the gateway to match each ‘frontend’ component running on the local device (browser, phone, workstation).
Plenty of memory. While there’s lots of FUD about how memory hungry Java is, it’s not entirely without merit. As Phil mentioned - keeping your DB separate from your Ignition instance is generally considered good practice, so that they aren’t fighting over the host’s memory.
Good disk speed. This isn’t very unique to Ignition, but especially in Ignition 8.0 and up, now that project resources are literally files on disk, high read speeds (i.e., some kind of SSD, over a spinning-disk) are going to pay dividends. Actual capacity on that disk is not likely to be a big deal - Ignition itself takes up just over a gigabyte, but that’s almost entirely the different runtimes we bundle for Windows, Linux, and MacOS. Your actual Ignition configuration is almost certainly going to be in the tens of megabytes - over 100 megabytes is probably the 99th percentile of gateway backups.

4 Likes
4

Perspective client requirements are pretty minimal. Any device with a modern web browser (HTML 5/CSS 3) will run it. This includes mobile (IOS/Android) and thin clients.

For servers, more is better and “it depends” on usage. In general, 16GB RAM and 4+ modern CPU cores (8+ threads), especially “server” grade, will provide significant capability. Going to 8 core and 32GB would be a good bet for the future. “Bare metal” servers are best, but VMs can be configured for performance (e.g. VMWare “latency sensitivity” setting to high). At a point not far beyond that, large CPU and RAM investments will not add much - other bottlenecks become significant (disk, I/O, etc). At that point a “scale-out” architecture delivers. This happens at a pretty modest point from the perspective of modern server hardware.

More details:
For “I/O” functionality, such as: tag hosting (up to >100k tags), database connectivity, alarming, SFCs, reporting, historian. 4 modern CPU cores/8 threads, 16 GB RAM. More memory is better for many Ignition tags. More CPU capability for large historian and reporting capability. When “scaling out” these are “stateful”, so use Redundant Ignition servers and just keep adding. Anecdotally, I’ve heard of a customer using 12M tags with 24 I/O servers (Ignition gateways). At scale configuration becomes significant.

“Frontend” Ignition Gateways. Responsible for Perspective/Vision sessions. 8GB+ RAM (recommend 16+), 4 modern CPU cores (8+ threads). More CPU is better. These are “stateless”, so do not use Ignition Redundancy with “scaling out” architecture. If scaling (past ~100-200 concurrent clients), recommend using a load balancing scheme with “Sticky Sessions”. The workload will be split and gateways can come up or down with minimal client disruption. This scheme works well with cloud technologies.

SQL Database - Similar specs to I/O server. First step should be separating from Ignition gateway. Solid state storage is a must when writing rapidly (historizing large number of tag changes/sec). It’s possible to archive older data to slower storage. Leverage IT - configuration, maintenance, updates, security, backup, administration, standards will likely be more significant issues than hardware specs.

As Phil recommended, try out your setup with a free Ignition trial. I recommend consulting with IA or an experienced Integrator when getting into large architectures.

6 Likes
5

I wonder if NUMA principles would benefit performance of the ignition in hardware intensive applications? Is it on the horizon for the development? Any chance you share your insight on that?

6

NUMA would have to be applied at the JVM layer, not Ignition. I don't know of any ongoing work with that.

1 Like
7

Java 7 introduced some amount of NUMA support, behind a flag, but only for a particular garbage collector:
https://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#numa

It looks like Java 14 added support for NUMA-aware allocation to G1GC, the current standard garbage collector, so once we update Ignition to Java 17 you'll be able to take advantage:
https://openjdk.org/jeps/345

2 Likes
8

@PGriffith thanks a lot for adding this