vlsi commented on issue #5966: URL: https://github.com/apache/jmeter/issues/5966#issuecomment-1630172337
>When they wait too long they will kill the mobile app and re longin again. >We cannot limit them. It's not real. You are right limiting threads is not realistic for systems like `google.com`, however, if the limit is reasonably high, then it it might be enough to reach the target workload, and at the same time it might be low enough to keep JMeter from failing with `OutOfMemoryError`. --- >We cannot limit them. It's not real There are cases when thread limit is expected for a production system. Imagine there's an internal application with 100 users only. The new users won't automatically appear, and they will not open 20 browser tabs trying to complete their work with 20 tabs simultaneously. So if we set JMeter's limit to 100, and test shows "not enough threads to reach the desired workload", it would effectively mean we need to optimize the software or recruit more workers. --- "thread lifetime" sounds like an interesting idea. The current "thread lifetime" for OMTG is "single execution". In other words, if OMTG is configured for 100 requests, each of them uses its own `JMeterThread` with its own variables and cookies. However, it looks like "thread lifetime" alone is not enough. Imagine the following: `thread_lifetime(20 min) rate(1/min) random_arrivals(1 day)`. Suppose JMeter creates the first request, and it completes within seconds. Which thread should be used for the second request? Should JMeter reuse the existing one (it is still available for ~20 minutes) or should it create a new thread? It seems we would need `thread_reuse_percentage(42%)` so JMeter could know it should reuse one of the existing threads with 42% (which one?) and it should create a new one with 58%. So the scenario becomes `thread_lifetime(20 min) thread_reuse_percentage(42%) rate(1/min) random_arrivals(1 hour)`. Overall concurrency limit would fit nicely there as a precaution setting to prevent OOM: `thread_lifetime(20 min) thread_reuse_percentage(42%) max_concurrency(100) rate(1/min) random_arrivals(1 day)`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jmeter.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org