Performance, Scalability and High Availability
Audience:
System/Security AdministratorsSkill Prerequisites:
System Administration and Maintenance,Windows Server,SQL Server
Plant an App runs large applications with many users and high volumes of processes. It scales horizontally, by adding web servers behind a load balancer, and vertically, by giving servers more CPU and memory. With two or more web servers, it runs active-active: every server handles users at the same time, and the application stays available when one server stops.
This page describes the architecture, how to set up several active servers, sizing guidance, and a reference deployment in production.
Architecture
| Tier | What it does | How it scales | High availability |
|---|---|---|---|
| Load balancer | Ends HTTPS, spreads requests across the web servers, checks their health | Your load balancer or appliance | Usually a redundant pair, or a cloud load balancer |
| Web servers | IIS with Plant an App: pages, forms, listings, APIs, workflows, automation | Add servers (horizontal) or more CPU and RAM per server (vertical) | Two or more active servers. If one stops, the others keep serving. |
| Shared file storage | The site files: application files, uploads, generated documents | Storage capacity and throughput | A highly available file share (SMB cluster, DFS, or a cloud file service) |
| Database | Microsoft SQL Server: all application data | More CPU, RAM and faster disks | SQL Server Always On availability groups or a failover cluster instance |
All web servers share the same site files and the same database, so any server can handle any request.
High Availability: Active-Active Web Servers
Use two or more web servers. To set them up as a web farm:
- Shared site files. Put the site folder on a shared file storage and point the IIS site on every server to it. Use the same IIS settings and application pool on every server. See the Installation Guide.
- Web farm mode. In
web.config, add<add key="IsWebFarm" value="true" />to<appSettings>. - Cache synchronization. In Settings > Servers > Server Settings > Performance, set Caching Provider to SimpleWebFarmCachingProvider. Servers then tell each other when cached data changes. Every server must be reachable from the others by its own name or address.
- Server monitoring. In Settings > Scheduler, set Monitor Web Servers to run every 5 minutes. The platform then registers new web servers automatically, and removes servers that stop reporting.
- Load balancer.
- Turn on session affinity (sticky sessions).
- Use a health check, for example
GET /login. - End HTTPS at the load balancer, or on each server.
- Database. Use a highly available SQL Server, for example an Always On availability group. Point the connection string at the listener and add
MultiSubnetFailover=Truewhen the replicas are in different subnets.
Automation jobs in a web farm. With IsWebFarm on, scheduled Automation jobs run on one server only, the first active server. Each job runs once, not once per server. If that server stops, another server takes over the jobs.
The same setup applies when Plant an App runs in containers. See Installation in Windows Containers.
Sizing
Size the servers for your users, data volumes and processes. Then confirm with a load test on a copy of production, with realistic data.
Starting point for an organization with about 1,000–1,500 internal users:
| Tier | Starting point | Scale when |
|---|---|---|
| Web servers | 2 or more servers, each with 2–4 vCPU and 4–8 GB RAM | Average CPU stays above 70%: add a server |
| SQL Server | 8 vCPU, 32 GB RAM, SSD storage | CPU, memory or disk waits stay high |
| Shared file storage | Sized for the documents and uploads you keep | Throughput or latency limits are reached |
The minimum for a single small installation is in the hardware requirements.
Reference Deployment
A large national organization runs one of its core operational applications on Plant an App, in production since July 2025. Staff across the country register records and record status changes, and partner platforms send data through the API.
All figures below are real and verified. They come directly from the production database of this live deployment, not from estimates, simulations or load tests. They were measured on 9 November 2026 with read-only aggregate queries, and cross-checked between independent sources (sign-in log, transaction records, web farm registry, API audit log).
Infrastructure
| Item | Value |
|---|---|
| Web tier | 2 web servers, active-active, in an auto-scaling group of Windows Server 2022 servers (2 vCPU, 4 GB RAM each), behind a load balancer with session affinity. New servers are added when average CPU passes 70%. |
| Shared storage | Shared file system mounted on all web servers |
| Database | SQL Server, single instance, 8 vCPU, 32 GB RAM, SSD |
| Platform | Plant an App 1.28 |
Users
| Metric | Value |
|---|---|
| Registered internal users (staff nationwide) | 23,956 |
| Users signed in during the last 30 days | 3,250 |
| Users who made transactions during the last 30 days | 1,667 |
| Users who made transactions in one day (peak) | 1,037 |
| Users who made transactions in the same hour (peak) | 471 |
| Users who made transactions in the same 15 minutes (peak) | 256 |
“Made transactions” means the user registered a record or recorded a status change. People who only looked something up aren't counted, so these are lower bounds for the number of users online.
Volumes
| Metric | Value |
|---|---|
| Records registered | 1.0 million |
| Status changes recorded | 434,000 |
| Records per day (October 2026 average) | about 21,000 |
| Records created in one day (peak) | 76,700 |
| Records created in one hour (peak) | 32,600 |
From October 2026, partner platforms send most records through the platform's API. Monthly volume grew more than tenfold, from 61,000 records in September to 652,000 in October, on the same 2 web servers.
Load and Response Times
| Metric | Value |
|---|---|
| API calls logged (May 2025 – November 2026) | 20.6 million |
| API calls in one day (peak) | 1.36 million |
| API calls in one hour (peak) | 74,000, sustained at about 70,000 an hour for more than 20 hours |
| API response time, server-side, last 30 days (4.1 million calls) | p50 60 ms · p95 105 ms · p99 151 ms |
| Server errors (HTTP 5xx), all API calls | 1,782 (0.009%) |
| Automation runs per day | about 5,000 (96% successful) |
API figures come from the platform's built-in API audit log and cover API traffic. Response times are measured on the server and don't include the network.
Performance Best Practices
- Index the columns you filter and join on. See Custom Index Behavior and Join Performance with External Systems.
- Keep transactions short and update tables in the same order everywhere, to avoid deadlocks. See Database Transaction Standardization and Deadlock Guidance.
- Move long work out of the request. Use Automation jobs or Execute Actions Asynchronously for imports, exports and calls to slow systems.
- Page large lists in listings, and load only the columns you show.
- Store large files outside the database, on a local disk, a network share or cloud storage. See File Storage.
- Monitor CPU, memory and request times on the web servers, and CPU, waits and disk latency on SQL Server.
Revised 11/12/2026