4 ms·
I don't really understand how this analogy works in terms of the actual practice of running load tests. You should of course test the full flow, the important p
by sparsely 4y ago
I don't really understand how this analogy works in terms of the actual practice of running load tests. You should of course test the full flow, the important part is not implicitly limiting the input volume based on the system performance. I think in your analogy it would be something about people queuing outside without you noticing but am unsure.
Also, to be clear, the bad thing is normally doing closed workload tests, not having a multistep workflow or whatever (https://gatling.io/docs/gatling/reference/current/core/injection/ https://gatling.io/docs/gatling/reference/current/core/injec...)
- ericb 4y agoTo complete the analogy, you need to have one concurrent session per "virtual user." This is the "concurrency" of the test. In my bad test, I had one concurrent user driving all the throughput--me. If I had targeted 200 concurrent users, I would have seen a failure in my test and found what the real throughput would be. Each concurrent user uses many resources that could be limited. In the restaurant, it is tables, plates, silverware. In a web app, it is sessions, connections, memory, database connections, and many other resources that can be associated with each session, and each may be a potential bottleneck that limits your actual throughput. If we target throughput and ignore concurrency, we set ourselves up for failure. In practicality, the better load testing tools let you create "concurrent users." In JMeter, this is the "threads." In other tools, it will be called "virtual users", "vus" or "sessions." In locust, the setting is -u NUM_USERS. The caution is not to fool yourself with high RPS if these settings aren't right for your test, and to normally target both.