Scaling Appian

As you build more applications and add more users, your sizing and scaling demands increase. This page provides guidance on several options for scaling your system, including which options are best for which situations, and how to know which options are most applicable to you.

Identify your scaling option

Use the symptom you are observing to determine which scaling option to apply:

Symptom	Suggested option
High load average in system.csv	Increase resource allocation
High Java work queue size in the engine performance logs	Add application servers
High other time in engine call summary log	Add engine replicas
Low idle time in the engine performance logs	Add execution and analytics shards
High execute time in perf_monitor_rdbms_slow.csv	Optimize your queries and applications and External data sources

Increase resource allocation

To increase memory or CPU allocation:

• Appian Cloud: Contact your account executive.
• Self-managed: Edit the Appian CR configuration file. See also: Resource Requests and Limits

Add application servers

Adding application servers addresses two types of load: user traffic and background processing.

User traffic

As more users interact with your Appian instance, the CPU and memory required by your application servers increases. Memory usage scales with the volume of concurrent user traffic—higher traffic means higher memory consumption per server.

To reduce the load on any single server, add more application servers so each one handles less traffic. Adding several smaller servers is preferable to replacing one server with a larger one, because it also improves resiliency. If one server out of five fails, the impact on users is much smaller than if a single large server fails.

Background processing

In addition to user requests, each application server handles background activity, including:

• Processing unattended process activities.
• Sending notification emails.
• Polling email inboxes.
• Timer events.

Each application server dedicates a fixed number of threads to background processing. If more background work is requested than a single server can handle, processing backs up, which can cause unexpected application behavior and delayed task completion.

To diagnose a background processing bottleneck:

1. Check the Work Queue - Java Work Queue Size in the engine performance logs.
2. Check the work item completion time in work_poller_summary.csv.

Use the results to determine the cause:

• Work queue size is increasing and work item completion time is low: The bottleneck is throughput. Adding application servers will speed up background processing.
• Work item completion time is high: The bottleneck is a downstream resource, such as a database. Adding application servers will not help—investigate the downstream system instead.

Configure application servers

To configure additional application servers:

Hosting Type	Action
Appian Cloud	Contact your account executive to add application servers to your environment.
Self-managed	Configure the spec.webapp.replicas field in the Appian CR configuration file.

Add engine replicas

By default, one instance of each Appian engine runs in your environment. Under high load, a single engine instance can become overwhelmed, resulting in poor performance. Adding replicas distributes read traffic across multiple instances, reducing contention.

How engine replicas work

• Read traffic is balanced across all instances of a given engine.
• Write traffic is executed by all engine instances. Write operations propagate asynchronously from the primary instance to replicas via a transaction log stored in Kafka.
• Replicas that are not current with the latest data reject read connections. Those requests are retried on the primary instance. During periods of heavy write load, balancing across instances is uneven, but you are protected from reading out-of-date data.
• Adding replicas increases total CPU usage, because write traffic runs on every instance. Expect higher CPU consumption even though individual response times improve.

Determine whether replicas will help

Check the Other Time column in engine_call_summary.csv. This value represents the time a user spends waiting for other users to finish using the engine. If this value is high, adding a replica will improve performance. The benefit is larger when the ratio of Read Count to Write Count is higher.

CPU requirements

Each Appian engine instance can use up to one full CPU. If you do not have enough CPUs to give each engine instance exclusive use of one, adding CPUs is easier than adding replicas and has lower ongoing maintenance overhead. Adding replicas without adequate CPU capacity produces little improvement in scale or performance.

Checkpointing behavior

• Self-managed: Checkpointing an engine is a blocking operation—all user traffic must wait for the checkpoint to complete. With more than one instance of a given engine, checkpointing runs on a replica, not the primary, allowing continued processing at temporarily reduced capacity. For uninterrupted operations during checkpoints, use a high-availability installation.
• Appian Cloud: Checkpointing is not a blocking operation. All engine instances remain available throughout the process.

Server requirements

Only one instance of any given engine can run on the same server. Adding engine replicas requires at least one additional server in a distributed installation.

Configure engine replicas

• Appian Cloud: Contact your account executive about the high-availability offering.
• Self-managed: Configure the spec.serviceManager.replicas and spec.serviceManager.engineOverrides[<ENGINE>].replicas fields in the Appian CR configuration file.

Add execution and analytics shards

Appian distributes process data across shards of the execution and analytics engines. Data for any individual process lives on exactly one execution shard and one analytics shard. Sharding keeps memory usage lower than a single-process design and allows the engines to use more than one CPU, since the one-CPU limit applies per shard.

Determine whether shards will help

Adding shards improves performance only when unused CPU capacity is available for the new shards to use. If your system is CPU-constrained, adding shards will not improve performance.

To check whether shards will help, look at the Idle Time column in the engine performance logs for the execution engines. Low idle times indicate that additional shards will likely improve performance.

Shard considerations

• Memory: Each shard replicates a set of common data (users, data type definitions, rules, and similar). Adding shards increases total system memory usage compared to running fewer shards for the same number of processes.
• Shard parity: The execution and analytics engines must always have the same number of shards.
• Default and maximum: Appian runs with 3 shards each by default. The maximum is 32 shards per engine.
• Irreversible: Because shards store unique data, you cannot remove a shard after adding it.

Configure shards

• Appian Cloud: Contact your account executive to add shards.
• Self-managed: Configure the spec.serviceManager.topology.analyticsExecShardCount field in the Appian CR configuration file.

Scale the data service

For Appian Cloud environments, the data service can automatically scale to match query throughput demand. You can use dynamic scaling for queries to dynamically provisions additional data service capacity within your environment to handle increased query demand. Available to all Appian Cloud environments.

For full details and how to enable it, see Dynamic scaling for queries.

Use a distributed RDBMS

For applications with heavy database workloads, hosting the RDBMS on dedicated servers improves capacity, reliability, and security. Dedicated servers are especially beneficial when application servers and engines compete for the same resources, creating performance bottlenecks.

Size the RDBMS servers

Assess RDBMS server requirements independently from your application and engine servers. Consider the following factors:

• Data volume: Current database size and projected growth over the next year.
• Concurrency: The number of simultaneous database connections your applications generate.
• Data movement: Read/write patterns and the volume of data transferred per operation.

RDBMS servers can typically be provisioned with fewer CPUs and less memory than application and engine servers.

Configure additional RDBMS servers

• Appian Cloud: Contact your account executive to configure additional RDBMS servers.
• Self-managed: See high availability.

Optimize your queries and applications

Application design has a direct impact on system scalability. Inefficient processes and interfaces create unnecessary load, and optimizing the applications used most frequently can significantly improve overall performance.

Developers building applications have considerable influence over how much load those applications place on the system. For guidance on optimizing performance, see:

• Interface Evaluation Lifecycle
• Query Best Practices

Manage your external data sources

Appian applications frequently connect to external systems via integrations, web services, data stores, or LDAP. An external system that cannot handle the load from your Appian applications will limit the scalability of your entire system.

Consult with the owners of any external systems your applications connect to. Discuss expected load levels and confirm that those systems have adequate capacity.

Feedback