The spreadscaler trait is a wadm deployment setting for a wasmCloud component. Its instances value declares how many component instances should run; increasing it lets concurrent requests run in parallel rather than queue behind one busy instance. The wasmCloud host runs replicas as separate component instances, while the NATS lattice distributes incoming requests among them. section 6.3 section 6.1
Start with the component’s expected workload. A single instance is adequate for a quick response, but a two-second operation exposes the bottleneck: five concurrent requests are processed sequentially, producing an average response time near eight seconds. Setting instances to 10 gives each tested request a replica and reduces average response time to just over two seconds. section 6.3
- type: spreadscaler
properties:
instances: 10
spread:
- name: eastcoast
weight: 80
requirements:
zone: us-east-1
- name: westcoast
weight: 20
requirements:
zone: us-west-1
Use spread to place a fixed replica count across hosts selected by labels. Each spread entry combines a name, a weight, and requirements; here, 80% targets hosts labeled us-east-1 and 20% targets us-west-1. section 6.4
Multiple hosts can represent separate machines, data centers, or regions. The spreadscaler load balances requests across eligible replicas regardless of location, and zone-aware placement can improve fault tolerance and reduce latency for nearby users. In a local simulation, independent hosts are started with --multi-local and zone labels, then wash get inventory verifies the resulting placement. section 6.4 section 6.7
Scale SmartCMS across two zones
A SmartCMS wadm.yaml assigns its HTTP component a spreadscaler with 100 instances. Its spread divides those instances 80:20 between eastcoast hosts requiring zone: us-east-1 and westcoast hosts requiring zone: us-west-1. The same manifest keeps the HTTP server as a capability linked to the component. section 6.6
A practical scaling loop is:
- Set instances in the component’s spreadscaler trait, then build and deploy the updated wadm.yaml. section 6.3
- Benchmark representative concurrency with oha to identify whether a single replica is queueing requests. section 6.3
- Add weighted spread requirements when replicas must be placed on hosts with particular zone labels. section 6.4
- Inspect host inventory after deployment to confirm labels and component counts match the intended distribution. section 6.4
