You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/configuration/index.mdx
+50Lines changed: 50 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -69,6 +69,22 @@ This table lists the environment variables and their default values.
69
69
|`AWS_ACCOUNT_ID`| (none) |`<aws account id>`| Required when `QUEUE_BACKEND=sqs` and `SQS_QUEUE_URL_PREFIX` is not set. Used to construct default SQS queue URLs. |
70
70
|`SQS_QUEUE_URL_PREFIX`| (none) |`<sqs queue url prefix>`| Optional override for SQS queue URL prefix (example: `https://sqs.us-east-1.amazonaws.com/123456789012/relayer-`). When set, `AWS_ACCOUNT_ID` is not required. |
71
71
|`SQS_QUEUE_TYPE`|`auto`|`auto, standard, fifo`| SQS queue type. `auto` (default) probes the `transaction-request` queue at startup to detect the type. `standard` and `fifo` skip probing and use the specified type directly. |
72
+
|`SQS_TRANSACTION_REQUEST_WAIT_TIME_SECONDS`|`15`|`0-20`| SQS long-poll `WaitTimeSeconds` for the transaction request queue. Lower values reduce pickup latency on bursty queues at the cost of more SQS API calls during idle periods. Only applies when `QUEUE_BACKEND=sqs`. |
73
+
|`SQS_TRANSACTION_SUBMISSION_WAIT_TIME_SECONDS`|`15`|`0-20`| SQS long-poll `WaitTimeSeconds` for the transaction submission queue. Same trade-off as the request queue setting above. |
74
+
|`SQS_STATUS_CHECK_WAIT_TIME_SECONDS`|`5`|`0-20`| SQS long-poll `WaitTimeSeconds` for the generic status check queue. |
75
+
|`SQS_STATUS_CHECK_EVM_WAIT_TIME_SECONDS`|`5`|`0-20`| SQS long-poll `WaitTimeSeconds` for the EVM status check queue. |
76
+
|`SQS_STATUS_CHECK_STELLAR_WAIT_TIME_SECONDS`|`3`|`0-20`| SQS long-poll `WaitTimeSeconds` for the Stellar status check queue. |
77
+
|`SQS_NOTIFICATION_WAIT_TIME_SECONDS`|`20`|`0-20`| SQS long-poll `WaitTimeSeconds` for the notification queue. |
78
+
|`SQS_TOKEN_SWAP_REQUEST_WAIT_TIME_SECONDS`|`20`|`0-20`| SQS long-poll `WaitTimeSeconds` for the token swap request queue. |
79
+
|`SQS_RELAYER_HEALTH_CHECK_WAIT_TIME_SECONDS`|`20`|`0-20`| SQS long-poll `WaitTimeSeconds` for the relayer health check queue. |
80
+
|`SQS_TRANSACTION_REQUEST_POLLER_COUNT`|`1`|`<any positive number>`| Number of concurrent SQS `ReceiveMessage` loops for the transaction request queue per task. More pollers improve message pickup smoothness on bursty queues. All pollers share the same handler concurrency semaphore. |
81
+
|`SQS_TRANSACTION_SUBMISSION_POLLER_COUNT`|`1`|`<any positive number>`| Number of concurrent SQS `ReceiveMessage` loops for the transaction submission queue per task. |
82
+
|`SQS_STATUS_CHECK_POLLER_COUNT`|`1`|`<any positive number>`| Number of concurrent SQS `ReceiveMessage` loops for the generic status check queue per task. |
83
+
|`SQS_STATUS_CHECK_EVM_POLLER_COUNT`|`1`|`<any positive number>`| Number of concurrent SQS `ReceiveMessage` loops for the EVM status check queue per task. |
84
+
|`SQS_STATUS_CHECK_STELLAR_POLLER_COUNT`|`1`|`<any positive number>`| Number of concurrent SQS `ReceiveMessage` loops for the Stellar status check queue per task. |
85
+
|`SQS_NOTIFICATION_POLLER_COUNT`|`1`|`<any positive number>`| Number of concurrent SQS `ReceiveMessage` loops for the notification queue per task. |
86
+
|`SQS_TOKEN_SWAP_REQUEST_POLLER_COUNT`|`1`|`<any positive number>`| Number of concurrent SQS `ReceiveMessage` loops for the token swap request queue per task. |
87
+
|`SQS_RELAYER_HEALTH_CHECK_POLLER_COUNT`|`1`|`<any positive number>`| Number of concurrent SQS `ReceiveMessage` loops for the relayer health check queue per task. |
72
88
|`DISTRIBUTED_MODE`|`false`|`bool` (`true/false`, `1/0`) | Enables Redis-based distributed locks for cron/cleanup tasks in multi-instance deployments, preventing duplicate scheduled execution across nodes. |
73
89
|`STORAGE_ENCRYPTION_KEY`| `` |`string`| Encryption key used to encrypt data at rest in Redis storage. See [Storage Configuration](./configuration/storage) for security details. |
74
90
|`RPC_TIMEOUT_MS`|`10000`|`<timeout in milliseconds>`| Sets the maximum time to wait for RPC connections before timing out. |
When running with `QUEUE_BACKEND=sqs`, two configuration dimensions affect message pickup latency:
268
+
269
+
**Wait time** (`SQS_*_WAIT_TIME_SECONDS`) controls the SQS `WaitTimeSeconds` parameter — how long each `ReceiveMessage` call blocks when the queue is empty. Lower values reduce worst-case pickup delay at the cost of more API calls during idle periods.
270
+
271
+
**Poller count** (`SQS_*_POLLER_COUNT`) controls how many concurrent `ReceiveMessage` loops run per queue per task. Each task runs one poll loop per queue by default. With multiple relayer tasks (instances), you get one poller per task — but during traffic bursts, messages can still sit visible briefly between poll cycles. Increasing the poller count adds more concurrent receivers sharing the same handler concurrency semaphore, improving pickup smoothness without increasing processing concurrency.
272
+
273
+
For high-throughput deployments (>50k transactions/hour), consider:
274
+
275
+
```bash
276
+
# Reduce long-poll wait from default 15s to 2s for the hot-path queues
277
+
SQS_TRANSACTION_REQUEST_WAIT_TIME_SECONDS=2
278
+
SQS_TRANSACTION_SUBMISSION_WAIT_TIME_SECONDS=2
279
+
280
+
# Run 3 poll loops per queue per task for smoother pickup
281
+
SQS_TRANSACTION_REQUEST_POLLER_COUNT=3
282
+
SQS_TRANSACTION_SUBMISSION_POLLER_COUNT=3
283
+
```
284
+
285
+
**Monitoring pickup latency**: The `transaction_processing_seconds` histogram exposes segment-level stages to help identify bottlenecks:
286
+
287
+
| Stage label | What it measures |
288
+
| --- | --- |
289
+
|`request_queue_dwell`| Time from transaction creation to request handler start (queue wait) |
290
+
|`prepare_duration`| Time spent preparing the transaction (simulation, signing, fee estimation) |
291
+
|`submission_queue_dwell`| Time from submission job enqueue to submission handler start (queue wait) |
292
+
|`submit_duration`| Time spent submitting the transaction to the network (RPC call) |
293
+
|`creation_to_submission`| End-to-end time from creation to network submission |
294
+
|`submission_to_confirmation`| Time from network submission to on-chain confirmation |
295
+
|`creation_to_confirmation`| Total lifecycle from creation to confirmation |
296
+
297
+
Use the dwell-time stages to determine whether tail latency comes from queue pickup delays (tune wait time/poller count) or from handler processing (tune RPC provider or concurrency).
298
+
249
299
## Main configuration file (config.json)
250
300
251
301
This file can exist in any directory, but the default location is `./config/config.json`.
0 commit comments