Add stress test scripts for submitter endpoints #954
+1,745
−116
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.

Linked Issues
Description
Added stress testing scripts for the submitter service to evaluate performance under load. These scripts test various endpoints:
stressTestCreateAccount.ts: Tests the account creation endpoint with configurable concurrent requestsstressTestExecute.ts: Tests the execute endpoint for processing boopsstressTestSimulate.ts: Tests the simulate endpoint for boop simulationstressTestSubmit.ts: Tests the submit endpoint with comprehensive receipt trackingutils/nonceMonitor.ts: Utility for monitoring executor nonces during testsEach script supports configurable parameters including concurrent requests, batch size, and delay between batches. They collect and report detailed metrics on success rates, latency (min, max, average, percentiles), and error distribution.
Toggle Checklist
Checklist
Basics
norswap/build-system-caching).Reminder: PR review guidelines
Correctness
testnet, mainnet, standalone wallet, ...).
< INDICATE BROWSER, DEMO APP & OTHER ENV DETAILS USED FOR TESTING HERE >
< INDICATE TESTED SCENARIOS (USER INTERFACE INTERACTION, CODE FLOWS) HERE >
and have updated the code & comments accordingly.
Architecture & Documentation
(2) commenting these boundaries correctly, (3) adding inline comments for context when needed.
Public APIS and meaningful (non-local) internal APIs are properly documented in code comments.
in a Markdown document.
make changesetforbreaking and meaningful changes in packages (not required for cleanups & refactors).