Show HN: Multiple – Load test any API with JavaScript and NPM packages
38 points| yevyevyev | 2 years ago |app.multiple.dev | reply
I wanted a better load testing solution – so I built one with my team at Multiple. We just opened early access and would love to get your feedback.
We created Multiple to solve three challenges with existing tools:
1. Limited scripting capabilities. XML or GUI-based scripting can only test basic scenarios. Existing code-based tools struggle with auth, generating synthetic data, and testing anything other than HTTP requests. We went with JavaScript for ease of use, versatility, and integration with existing developer workflows.
2. Cannot use existing libraries or code. Instead of forcing you to learn a new system and rewrite code, Multiple leverages the JavaScript and NPM ecosystem so you can use packages you're already familiar with. By supporting NPM packages, Multiple can test nearly any API, service, or protocol.
3. Tedious infrastructure management. There's no reason to spend time spinning up and configuring machines, and then destroying them after a test. Multiple abstracts that away. You just enter the test size and duration, and press start.
My favorite feature we've built so far is the Debug Run. You can use Debug Run as you write your tests to execute a single run-through. It's helpful to verify correct behavior and capture logs, and it allows you to iterate quickly, without spinning up a full load test each time.
We have so much in store for developers: pass/fail conditions, CLI, and repo integration, to name a few. Thanks for reading, and let us know what you think.
[+] [-] chatmasta|2 years ago|reply
Do you have a plan to avoid this? I think it can be solved with simple domain verification. Generate a unique key for the customer and ask them to insert it into a DNS TXT record to prove they control the domain you're about to spam with requests on the behalf.
However, given the flexibility of your platform, that might not be sufficient. If a user can write arbitrary scripts, then can they change the target mid-test? You might also need some kind of firewalling solution in place.
[+] [-] yevyevyev|2 years ago|reply
Accounts on the free tier won't be able to create much of an attack. We perform customer verification on accounts with higher concurrent virtual user limits.
We closely monitor potential abuse and will adjust our verification strategy as needed. Thanks for the question.
[+] [-] _acco|2 years ago|reply
[+] [-] yevyevyev|2 years ago|reply
> What's the warm-up time on tests?
Tests usually take 20-40 seconds to spin up. Tests with over 10k virtual may take up to 60 seconds to start.
> Any maximums on concurrent users this can simulate?
The free tier supports up to 50 virtual users. Paid tiers can go up to 50k virtual user
[+] [-] baristaGeek|2 years ago|reply
[+] [-] toddashley|2 years ago|reply
[+] [-] yevyevyev|2 years ago|reply
[+] [-] nrau|2 years ago|reply
I'd absolutely recommend anyone who needs load testing tooling and infrastructure to evaluate this service, and I am excited to see where they go.
[+] [-] baristaGeek|2 years ago|reply
[+] [-] yevyevyev|2 years ago|reply
[+] [-] vira28|2 years ago|reply
[+] [-] ashiban|2 years ago|reply
[+] [-] rfarley04|2 years ago|reply
[+] [-] yevyevyev|2 years ago|reply
One major update included with the CLI is a code repo integration - you can have your load test scripts in your codebase and track results to commits.
[+] [-] jahilliard|2 years ago|reply