TODO parametize the threads, user count, ramp up time and total seconds so can just add that on command line and don't need to rebuild the test in gui each time Instructions on doing exactly that here https://dev.to/raphael_jambalos/simulate-real-user-behavior-in-apache-jmeter-load-tests-58bl ================================== OLDER STUFF Goals 1) DEV READINESS: Find fail points that prevent release and need adjusting 2) MARKETING / HOSTING: Find out what kind of specific load (number of simultaneous users) a droplet can handle What are the bottlenecks specifically? Find out what categories of users can fit into which sized hardware i.e. a small shop with 10 users can infinitely use the tiniest droplet?? Does database size matter when it comes to load? (not specifically reporting on huge numbers of records for example, just normal sane operation) Load / capacity / stress testing Find problem areas - dev / pre-release Have an idea what hardware can support what load of users - marketing/ support / sales how far can it go before failure? what is the maxium simultaneous users for a given hardware config digital ocean can help with this as we can spin up progressively more peformant droplets and load / stress test them to know Does it recover from failure? Find prior unknown bugs that result in failure under stress todo: make sure it's simulating realistically, i.e. how users would really work with it as much as possible todo: add parameters for max of each object or read data and auto know, create objects, generate report,filterid todo: remove anything redundant, best to test each area of server, not every single route simpler is better for load testing, this isn't a completeness or acceptance test method leave that to cypress e2e todo: generate reports in load test todo: create records in load test avoid inventory affecting for the moment, too complex to test, just a customer or something simple for now # LINKS https://www.howtogeek.com/668986/how-to-use-the-linux-top-command-and-understand-its-output/