General walkthrough

[andromeda306]

Hi, having spent some time testing out this solution I've become increasingly confused by its functionality.
Can someone please clarify how exactly this solution works? I don't mean a technical run through of all the underlying components - more a clear explanation as to what/why is being run when I hit the 'Run Now' button in the context of a .jmx script. My use case is such that I have a hosted application frontend I'd like to load test to find out how many concurrent users the portal can handle.
From my underlying frontend infrastructure cpu/ram obviously handles the incoming traffic, however:

• is a task the same as a potential user? if yes/no why would I want to change the underlying cpu/ram?
• does the concurrency value just split the number of set tasks into more manageable groups?
• should my jmeter script make use of Threads to represent users? do they clash with the adjustable settings in the dashboard?
• am I approaching this solution correctly given my need to test for 100, 200.. 1000+ users?

[kamyarz-aws]

Hi @andromeda306

https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/determine-number-of-users.html
https://guide.blazemeter.com/hc/en-us/articles/360000864389-Calibrating-a-Taurus-Test-Calibrating-a-Taurus-Test

These could to some extent answer your question.

The solution uses Taurus which runs JMeter. The users are specified in the Taurus test configuration as well as their JMeter script. The way that Taurus works with JMeter thread groups is that when users are defined in both it use the Taurus defined users as the actual number and the JMeter users in each thread group as a proportional factor of the actual. For example if you define two JMeter thread groups with 100 and 200 users respectively, and define 75 users in the DLT solution (which is creating the Taurus configuration), the actual number of users run in each thread group will be 25 and 50. You can read more in the taurus documentation.