LoadSignalsOptions

The load signals a ConcurrencySystem watches to decide whether the machine is overloaded.

Each of the four built-in signals is configured by passing its options bag — shorthand for constructing the corresponding LoadSignal class yourself, so { cpu: { overloadedRatio: 0.5 } } is exactly { cpu: false, custom: [new CpuLoadSignal({ overloadedRatio: 0.5 })] }. Pass false to leave a resource unwatched, and put anything else you want taken into account in custom.

How far back the signals are evaluated is not set here, but by snapshotHistorySecs and currentHistorySecs.

Index

Properties

• cpu
• custom
• eventLoop
• memory
• storageBackend

Properties

optionalcpu

cpu?: false | CpuLoadSignalOptions

Tuning for the built-in CpuLoadSignal (overload ratio), or false to switch it off.

optionalcustom

custom?: LoadSignal[]

Additional LoadSignal implementations — e.g. navigation timeouts or proxy health — evaluated alongside the built-in four. If any signal reports overload, the system counts as overloaded. Their lifecycle is driven by the ConcurrencySystem they are given to, and their names must not collide with an enabled built-in's.

optionaleventLoop

eventLoop?: false | EventLoopLoadSignalOptions

Tuning for the built-in EventLoopLoadSignal (snapshot interval + blocked-millis limit + overload ratio), or false to switch it off — which also stops its measuring interval.

optionalmemory

memory?: false | MemoryLoadSignalOptions

Tuning for the built-in MemoryLoadSignal (used-memory limit + overload ratio), or false to switch it off.

optionalstorageBackend

storageBackend?: false | StorageBackendLoadSignalOptions

Tuning for the built-in StorageBackendLoadSignal (snapshot interval + error limit + overload ratio), or false to switch it off — worth doing when the storage backend reports no rate-limit statistics, since the signal otherwise polls it every second to no purpose.