-
Notifications
You must be signed in to change notification settings - Fork 37
DOC-313: Kinesis: add option for a rust based mock #731
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -170,21 +170,44 @@ You can fetch the CloudWatch logs for your Lambda function reading records from | |
|
|
||
| ### Performance Tuning | ||
|
|
||
| For high-volume workloads or large payloads, we recommend switching to the Scala engine via the `KINESIS_MOCK_PROVIDER_ENGINE=scala` flag, delivering up to 10x better performance compared to the default Node.js engine. | ||
| By default, Kinesis Mock runs on the Node.js engine (`KINESIS_MOCK_PROVIDER_ENGINE=node`). | ||
| For high-volume workloads, large payloads, or long-running setups, you can switch to a different engine using the `KINESIS_MOCK_PROVIDER_ENGINE` flag. | ||
|
|
||
| Additionally, the following parameters can be tuned: | ||
| #### Scala engine | ||
|
|
||
| The Scala engine (`KINESIS_MOCK_PROVIDER_ENGINE=scala`) delivers up to 10x better performance compared to the default Node.js engine. | ||
| The following parameters can be tuned for the Scala engine: | ||
|
|
||
| - Increase `KINESIS_MOCK_MAXIMUM_HEAP_SIZE` beyond the default `512m` to reduce JVM memory pressure. | ||
| - Increase `KINESIS_MOCK_INITIAL_HEAP_SIZE` beyond the default `256m` to pre-allocate more JVM heap memory. | ||
| - Reduce `KINESIS_LATENCY` artificial response delays from the default `500` milliseconds (or disable entirely with `0`). | ||
|
|
||
| Refer to our [Kinesis configuration documentation](https://docs.localstack.cloud/references/configuration/#kinesis) for more details on these parameters. | ||
|
|
||
| :::note | ||
| `KINESIS_MOCK_MAXIMUM_HEAP_SIZE` and `KINESIS_MOCK_INITIAL_HEAP_SIZE` are only applicable when using the Scala engine. | ||
| Future versions of LocalStack will likely default to using the `scala` engine over the less-performant `node` version currently in use. | ||
| ::: | ||
|
|
||
| #### Rust engine | ||
|
|
||
| The Rust engine (`KINESIS_MOCK_PROVIDER_ENGINE=rust`), introduced in LocalStack 2026.07, is a LocalStack-native rebuild of Kinesis Mock and is the recommended choice for any demanding or long-lived workload. | ||
| It provides: | ||
|
|
||
| - **Native multi-account and multi-region support** from a single binary, regardless of how many accounts you use — this removes the per-account instance overhead described under [Limitations](#limitations). | ||
| - **Faithful enforcement of all AWS API limits**, including per-shard rate ingress/egress limits. | ||
| - **An improved persistence model** that replaces the legacy unbounded in-memory queue, allowing the mock to run under sustained load for long periods without the risk of running out of memory. | ||
|
|
||
| :::caution | ||
| This is the first release of the Rust engine and it should be considered experimental for anyone opting in. | ||
|
|
||
| Persistence is **not compatible** between the Rust engine and the Node.js or Scala engines, in either direction. | ||
| Any existing Kinesis persistence (including Cloud Pods and state created with the `node` or `scala` engines) will not carry over when you switch to `rust` — and vice versa. | ||
| Switching engines effectively starts from a fresh state. | ||
| ::: | ||
|
|
||
| #### All engines | ||
|
|
||
| Regardless of the selected engine, you can reduce `KINESIS_LATENCY` artificial response delays from the default `500` milliseconds (or disable them entirely with `0`). | ||
|
|
||
| Refer to our [Kinesis configuration documentation](https://docs.localstack.cloud/references/configuration/#kinesis) for more details on these parameters. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hey @jbeemster, we don't have a (this looks like an old link from the v1 docs site from over a year ago) It would be helpful to know where this old url came from, such as did you find in in search results? Want to double check if I need to update the 301s for this repo.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It was a link that got moved from the old section - see line 181 in this diff! |
||
|
|
||
| ## Resource Browser | ||
|
|
||
| The LocalStack Web Application provides a Resource Browser for managing Kinesis Streams & Kafka Clusters. | ||
|
|
@@ -209,8 +232,10 @@ The following code snippets and sample applications provide practical examples o | |
|
|
||
| ## Limitations | ||
|
|
||
| In multi-account setups, each AWS account launches a separate instance of Kinesis Mock, which is very resource intensive when a large number of AWS accounts are used. | ||
| [This Kinesis Mock issue](https://github.com/etspaceman/kinesis-mock/issues/377) is being used to keep track of this feature. | ||
| When using the default Node.js or the Scala engine, each AWS account launches a separate instance of Kinesis Mock in multi-account setups, which is very resource intensive when a large number of AWS accounts are used. | ||
| [This Kinesis Mock issue](https://github.com/etspaceman/kinesis-mock/issues/377) is being used to keep track of this feature for the upstream engines. | ||
|
|
||
| The [Rust engine](#performance-tuning) (`KINESIS_MOCK_PROVIDER_ENGINE=rust`) is not affected by this limitation, as it natively supports any number of accounts and regions from a single binary. | ||
|
|
||
| ## API Coverage | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its hard to benchmark Scala vs Rust accurately as Scala does not adhere to API data plane limits like 1MiB/s ingress rates per shard but all of my tests show lower CPU + Memory usage and equivalent or better throughput once shards are scaled up high enough for the Rust side to really get going.