by chatmasta on 11/28/2023, 5:54:10 PM
by _acco on 11/28/2023, 2:51:16 PM
Looks neat! What's the warm-up time on tests? Any maximums on concurrent users this can simulate? (does warm-up time increase with # concurrent users?)
by toddashley on 11/28/2023, 3:36:50 PM
Congrats! Excited to play with this. For anyone else looking for the docs I found them through the landing page (the top level post direct links to the app): https://docs.multiple.dev/quick-start-guide
by nrau on 11/29/2023, 12:21:30 AM
I tried Multiple's service out in an early beta preview, and was impressed with the flexibility of the initial product. Customer service and support was very good as well. The current product roadmap will be adding a lot of compelling features in the coming months.
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.
by baristaGeek on 11/28/2023, 2:56:31 PM
Great product! I really liked the UI/UX, and the fact that you provide an example is awesome. I played around with it for about 10 minutes, but one thing wasn't entirely clear to me: How do I import my API if it's not an NPM package?
by vira28 on 11/28/2023, 6:03:22 PM
Haven't played with the product itself, but I have known Yev for some time now. Sure he and the team will do something meaningful in this space. All the best.
by ashiban on 11/28/2023, 4:40:19 PM
Big fan of Multiple! You should give your designer an extra Hi5
by rfarley04 on 11/28/2023, 6:26:12 PM
You mentioned CLI. When is that coming and what will it do?
by jahilliard on 11/28/2023, 3:52:52 PM
Awesome! Love how JS forward it is.
One problem with products like this is that the same marketing materials are used by DDoS vendors. In their case of course "load testing" is coded language for "DDoSing a target." But nonetheless, you run the risk of people abusing your service to "load test" services they don't control, which could lead to high bills on your side that might never even get paid (people who DDoS others tend to have a lot of overlap with people who pay with stolen credit cards).
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.