I previously used https://k6.io/ https://k6.io/ in lieu of better options. It was great for getting up and running reasonably quickly (and generating lots of re

I previously used https://k6.io/ https://k6.io/ in lieu of better options. It was great for getting up and running reasonably quickly (and generating lots of requests in parallel), but also kind of had a weird JS runtime so the error messages weren't always intuitive so debugging was a pain. Then again, could also use anything like Apache JMeter (https://jmeter.apache.org/ https://jmeter.apache.org/), Gatling (https://gatling.io/open-source/ https://gatling.io/open-source/) or any other solution out there, whichever is better suited for the on-prem/cloud use case. That said, when time was limited and I didn't have the time to figure out how to test WebSocket connections and which resources the test should load, I cooked up a container image with Selenium (https://www.selenium.dev/ https://www.selenium.dev/) with Firefox/Chrome as a fully automated browser, for 1:1 behavior as real users would interact with the site. That was a horrible decision from a memory usage point of view, but an excellent one from time-saving and data quality perspectives, because the behavior was just like having 100-1000 users clicking through the site. Apart from that, you probably want something to aggregate the performance data of the app, be it something like Apache Skywalking (https://skywalking.apache.org/ https://skywalking.apache.org/) or even Sentry (https://sentry.io/welcome/ https://sentry.io/welcome/). Then you can probably ramp up the tests slowly over time in regards to how many parallel instances are generating load and see how the app reacts - the memory usage, CPU load, how many DB queries are done etc.