Select Hardware Sizing
Review the recommendations for the ThingWorx Foundation Nodes and desired database(s). Cloud provider options and storage speed recommendations follow the charts.
* 
Recommendations were identified through tests performed on Azure Linux (Ubuntu 18.04 LTS) Fsv2 Virtual Machines. Premium SSDs were used for all database instances. Results may differ on other cloud providers, physical hardware, or operating system combinations.
Size
ThingWorx Foundation (each node)
Relational DB
(SQL Server or PostgreSQL)
Relational DB
(Azure PostgreSQL Flexible)
Time-Series DB Data Node(s)
(InfluxDB)
X-Small H2*
(H2 in-memory DB)
4 vCPUs
8 GiB RAM
Small H2*
(H2 in-memory DB)
8 vCPUs
16 GiB RAM
Small(RDBMS Only)
8 vCPUs
16 GiB RAM
8 vCPUs
16 GiB RAM
16 vCPUs
64 GiB RAM
1 TB
Small +(with InfluxDB**)
8 vCPUs
16 GiB RAM
4 vCPUs
8 GiB RAM
4 vCPUs
8 GiB RAM
Medium(RDBMS Only)
16vCPUs
32 GiB RAM
16vCPUs
32 GiB RAM
16 vCPUs
64 GiB RAM
1 TB
Medium +(with InfluxDB**)
16vCPUs
32 GiB RAM
8 vCPUs
16 GiB RAM
8 vCPUs
16 GiB RAM
Large(RDBMS Only)
32vCPUs
64 GiB RAM
32vCPUs
64 GiB RAM
32 vCPUs
128 GiB RAM
2 TB
Large +(with InfluxDB**)
32vCPUs
64 GiB RAM
16 vCPUs
32 GiB RAM
16 vCPUs
32 GiB RAM
Large (HA) + Azure Flex HA
48 vCPUs
192 GiB RAM
8 TB
Reminder: Sizing Guide recommendations are intended for use initial baselines to size ThingWorx implementations. Individual results will vary based on edge configuration, application load, etc.
* The H2 in-memory database is not supported for production implementations.
** ThingWorx can use either the open-source, single node version of InfluxDB, or an InfluxDB Enterprise cluster for high availability and increased performance. The InfluxDB open-source version was used for these sizing tests. For InfluxDB Enterprise sizing, plan for two InfluxDB “Data” nodes as indicated, plus three “Meta” nodes, typically 1-2 vCPUs and 0.5-1GiB RAM each. For more guidance on InfluxDB sizing, please review https://docs.influxdata.com/influxdb/v1.8/guides/hardware_sizing/.
* 
Azure PostgreSQL Flex Server needs more computing and storage than the on-prem database to achieve a similar Value Stream queue rate. Components like max IOPS and IOPS bandwidth depend on compute and storage size.
Microsoft Azure
Azure provides a variety of instance types to fit your use cases. PTC recommends computed optimized, hyper-threaded instance types for most use cases - primarily the Fsv2-Series.
Microsoft describes Azure Fsv2-Series instances as VMs that "... support 2-GiB RAM and 8-GB of local temporary storage (SSD) per vCPU(s), and are optimized for compute intensive workloads."
Other instance types such as the general purpose Dsv3-series may also be considered based on the requirements on the application being deployed:
F-class (Compute Optimized) VMs are often well suited for high-speed data ingestion with less complex business logic or event processing.
D-class (General Purpose) VMs are often well suited to ThingWorx applications that prioritize high device counts whose states need to be retained in memory.
CPU clock speed may need to be considered for your use case. Fsv2 features slightly higher CPU clock speeds than Dsv3, which can have a visible impact for workloads where fast, high-volume event processing is required.
Azure provides a packaged method for selecting a VM in terms of CPU cores. Typical sizing terms are F2s_v2, F4s_v2, F8s_v2, etc. where the number represents the number of CPU cores in the VM.
Following the example in the above on-premise terminology, a small ThingWorx Platform using the H2 database may be sized to run on a F8s_v2 VM, but based on your requirements you might chose to deploy a D8s_v3 if your application requires a larger memory footprint per ThingWorx Foundation node.
Microsoft also regularly adjusts and improves their VM offerings. For more details on Azure VM specifics, see the Azure website: https://azure.microsoft.com/en-us/pricing/details/virtual-machines/series/
Traditional On-Premise Terminology
Traditional or on-premise hardware sizes are typically discussed in terms of CPU cores for processing power and RAM for memory capability. For example, a small ThingWorx Platform using the H2 database may be sized at 8 CPU cores and 16 GB RAM.
It is recommended to give the database its own server to ensure that there is no single point of failure in the application configuration.
Amazon Web Services (AWS) Terminology
For EC2 instances, AWS provides a selection of instance types. PTC recommends the compute optimized series, the latest of which is the C5d series. AWS states that these instance types "are optimized for compute-intensive workloads and deliver cost-effective high performance at a low price per compute ratio."
AWS provides a t-shirt methodology for selecting the size of an EC2 instance in terms of CPU and memory. Typical sizing terms are large, xlarge, 2xlarge, etc.
Following the example in the above on-premise terminology, a small ThingWorx Platform using the H2 database may be sized to run on a C5d.2xlarge EC2 instance. Other EC2 instance types, such as General Purpose (M) and Memory Intensive (R), can also be considered based on the CPU-to-memory ratios needed for your application load, but are not covered in this guide.
For more details on Amazon EC2 instance type specifics, see the AWS website: https://aws.amazon.com/ec2/instance-types/.
High Speed Storage
In general, PTC recommends using high-speed storage for ThingWorx to support concurrent data ingestion, processing, and visualization.
Slower storage options can lead to hard-to-diagnose performance and scale challenges for both ThingWorx and the databases it relies on. These challenges can also have unexpected external influences, such as system backups, operating system, or database level data fragmentation, or cleanup activities running on the same storage device or controller.
Solid State Disk (or SSD) options exist for each of the cloud vendors recommended and should be considered whenever possible for both the platform and for the database implementations.
High-speed hard disk drive (HDD) options may also be considered, especially for data that will change or be accessed less frequently.
Review the ThingWorx System Requirements for additional details.
Was this helpful?