jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <sitnikov.vladi...@gmail.com>
Subject Re: Avoid thread sleep on delays
Date Mon, 14 Oct 2019 09:20:47 GMT
>Async IO

It might be tough.

>One for what is in fact a UserSession

I think we could wrap everything to JMeterThread class which could be
"thread context" that holds all the variables, states, etc.

>would be a clear improvement

There might be a flip side there :-/

For instance, the current JMeter implements "single-task" users.
In other words, a JMeter thread is sleeping for delays, that means if
ThreadGroup contains just one thread it would sleep a lot and it would do
noting during that delay.
On the other hand, if we allow the thread to switch context, that would
enable it to "multi-task" which would simulate the case when user is moving
among different computers (or browser tabs). Of course, each tab could be
slow, but the user is switching fast so it gets lots of work done in the
same amount of time.

Even though that "multi-tasking" would unlock the cases with long delays,
however, it might produce an unrealistic number of tasks completed.

Some examples:
1) "call center" test scenario. Suppose the call center has 10 operators
that receive the calls and run some actions.
Then we can configure 10 threads in JMeter, and use meaningful think times.
If the number of threads is "not enough" to complete the expected
number of tasks within a business day, that means "10 operators in the call
center are not enough and we need to hire new or optimize the system".
Multi-tasking here would harm by producing unrealistic number of operations
as real operators do not multi-task.

2) "personal profile" test scenario. Suppose we want to stress test a
personal profile page. In that case, we expect that the page might be used
by 100'000 users concurrently, however, they don't rush at the same time,
and the effective "think times" are high.
Multi-tasking would help here: we could create 10-20 JMeter threads that
would multi-task, so we don't need to create 100'000 threads.

It looks like an "Enable multi-tasking" option for a ThreadGroup which is
kind of sad because it complicates the UI.

What if we remove "Create threads only when needed" checkbox, and make that
a default? (==to reduce the number of UI elements)

Vladimir

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message