System Requirements & Performance Guidelines

This article provides general guidance for configuring and scaling SkylineGlobe Server (SGS) v8.5. The recommendations below are intended to help size hardware and infrastructure for typical production deployments. Actual performance depends on workload characteristics, deployment model, caching behavior and hardware resources.

In this article:

• Hardware and Software Requirements
• Deployment Options, Scalability and Redundancy
• User Session
• Computing and Memory Requirements
  • Caching Mechanisms
  • How Many Requests a Single Server Can Process
• Bandwidth and IOPS Allocation
  • Maps and Terrain Services
  • 3D Layers Service
  • Feature Service
  • Point Cloud Service
• Case Study

Hardware and Software Requirements

Deployment Options, Scalability and Redundancy

SkylineGlobe Server 8.5 offers multiple deployment configurations to support a wide range of infrastructure and scalability requirements. Windows deployments are fully supported on Windows 11 as well as Windows Server 2019, 2022, and 2025. For Linux environments, SkylineGlobe Server can be deployed using Docker and Kubernetes, typically running on Ubuntu 24.04 or other compatible distributions that support these container platforms.

You can deploy multiple SkylineGlobe Server instances behind a load balancer. Any standard hardware or software load balancer solution is supported. This applies both to traditional server deployments and to containerized environments using Docker or Kubernetes.

User Session

The configuration described below assumes an average session length of 15 minutes per user. 

Applications with shorter sessions typically generate higher peak data usage, as users tend to zoom into high-resolution areas and navigate more frequently. In longer sessions, after an initial exploration phase, users usually focus on a specific area of interest, resulting in lower sustained data consumption from SkylineGlobe Server.

Ultimately, application behavior determines user interaction patterns and therefore drives average bandwidth, storage, and compute requirements.

Computing and Memory Requirements 

In most cases, SGS uses minimal compute and memory resources for data streaming, since content is passed through without modification. However, certain content formats require additional server‑side processing at request time, depending on how the data is stored and how it is consumed by clients. Examples include:

• Streaming SLPK generated from 3DML or o3DML
• Streaming 3D Tiles derived from 3DML

Note that the o3DML format, used for both mesh and Gaussian Splatting, is natively optimized for 3D Tiles consumption and does not require compute‑intensive processing or reformatting during streaming.

Formats that require extra processing place greater load on the CPU and benefit significantly from caching. Once data is cached, repeated requests for the same content can typically be served with minimal processing, greatly improving overall throughput.

Caching Mechanisms

Some of the more CPU-intensive SGS services can benefit from the SGS caching mechanism that stores the output blocks in the required format and reuses them in future requests. This mechanism optimizes the CPU and memory utilization but may consume additional storage space.

Services that have caching mechanisms:

• DirectConnect terrain service - For optimized projects with imagery and elevation layers in MPT format, only fused blocks (up to 3% of the data) are saved in the cache. For DirectConnect projects, with imagery and elevation layers in non-optimized MPT format, the caching mechanism may store up to 100% of the data.
• 3D mesh services for 3D Tiles and SLPK. 
  Note that streaming 3DML format to TerraExplorer Desktop is optimized and doesn’t require caching.

How Many Requests a Single Server Can Process

The table below summarizes a test case measuring how many requests per second a single server can handle. The “number of blocks” represents both data‑block and index‑block requests. Actual performance may vary depending on data type, I/O throughput, and overall hardware configuration.

Test Case Hardware Configuration:

• CPU: 32 vCPU / 16 physical cores
• RAM: 128 GB
• Storage: AWS EBS gp3 (SSD)

Bandwidth and IOPS Allocation

This section describes the I/O and network bandwidth requirements for supporting an average SkylineGlobe user. Actual requirements depend on content type, user interaction patterns, caching behavior, and deployment architecture. It is important to ensure that the load balancer can handle the expected traffic load.

The following metrics are considered:

• I/O requests per second (IOPS)
• I/O read/write throughput (MB/s)
• Network bandwidth required (Mbps)

Maps and Terrain Services

For smooth map and terrain navigation, it is recommended to allocate 600 Kbps per concurrent user during average consumption. This bandwidth reflects the typical viewing pattern of a flight session, which alternates between higher-bandwidth panning or zooming actions and lower-bandwidth periods when the camera is focused on a specific area.

The 600 Kbps average corresponds to approximately 4 data-block requests per second, with each block averaging ~20 KB and representing a 256×256-pixel area.

During peak activity, such as rapid or continuous panning or zooming, terrain request rates can increase to 20 blocks per second, resulting in bandwidth usage of approximately ~3 Mbps per user.

3D Layers Service

3D Mesh Layers

For a smooth and responsive 3D mesh streaming experience, it is recommended to allocate 10 Mbps per concurrent user during average consumption. This value represents the average bandwidth over a complete flight session, accounting for both high-bandwidth navigation periods and lower-bandwidth intervals when the user remains focused on a specific area.

The 10 Mbps average corresponds to approximately 4 data-block requests per second, with an average block size of ~300 KB.

During peak activity, such as rapid or continuous panning or zooming, mesh request rates can rise to 15 blocks per second, resulting in bandwidth usage of approximately ~36 Mbps per user.

3D Gaussian Splatting Layers

For a smooth and responsive 3D Gaussian Splatting streaming experience, it is recommended to allocate 20 Mbps per concurrent user during average consumption. This value represents the average bandwidth over a complete flight session, accounting for both high-bandwidth navigation periods and lower-bandwidth intervals when the user remains focused on a specific area.

The 20 Mbps average corresponds to approximately 3 data-block requests per second, with an average block size of ~700 KB.

During peak activity, such as rapid or continuous panning or zooming, Gaussian Splatting request rates can rise to 9 blocks per second, resulting in bandwidth usage of approximately ~64 Mbps per user.

Feature Service

Recommended bandwidth and IOPS allocation for the Feature Service depends on the number of feature layers displayed and the complexity of each layer.

In a moderately complex environment, the Feature Service’s bandwidth requirements generally parallel those of the Terrain Service. An average flight session involving approximately 5 feature data-block requests per second, with each block around 10 KB, results in an average bandwidth requirement of ~450 Kbps per concurrent user.

Point Cloud Service

With the introduction of TerraExplorer Desktop 8.1, point cloud streaming efficiency has been significantly improved through data compression and optimized block sizing. These improvements reduce the number of requests and improve overall streaming performance. The numbers below reflect streaming CPT data generated by TerraExplorer Pro v8.1.

For a smooth and responsive point cloud streaming experience, it is recommended to allocate 15 Mbps for each concurrent user during average consumption. This value represents the average bandwidth over a complete flight session, accounting for both high-bandwidth navigation periods and lower-bandwidth intervals when the user remains focused on a specific area. 

The 15 Mbps average corresponds to roughly 7 data-block requests per second, with an average block size of ~200 KB.

During peak activity, such as rapid or continuous panning or zooming, point cloud request rates can rise to 15 blocks per second, resulting in bandwidth usage of approximately ~30 Mbps per user.

Case Study

The following example provides general sizing guidance for an environment serving 50 active users of SkylineGlobe Server. Actual performance depends on CPU cores, NVMe/SSD storage, memory, caching, and network bandwidth, but the estimates below provide a practical starting point. 

A typical user session contains a mix of terrain, 3D and feature layers which may behave differently than a session containing only a single layer. Viewer-side behavior (TerraExplorer and other 3D clients) also affects request rates, as clients regulate requests based on both server ability to stream and the viewer's ability to process them.