Lets say we have 2 thread groups, one has 10 threads, another one has 30 threads. I have unchecked "run thread group consecutively". In table results, we see response time of second thread group is more than first threadgroup users.
When threadgroups are arranged other way, it shows reverse. So, whichever is second thread group, its user showing response time more than what is there in first thread group.
When you unchecked the "run thread group consecutively", then both the thread group runs in parallel. Now, based on the number of thread they will send the requests. In your scenario, 2nd thread group has created 30 threads and start sending the request. Now, based on,after how much time the response will come, it is listed in the view result. So, you thread group have more thread and may be getting response faster then thread 1. But, thread 1 is also going to be listed in the view results as shown below;-
Option is unchecked, so parallel running:-
So,in short, if "run thread group consecutively" option is unchecked, thread groups will run in parallel else sequential.
Option is checked, so sequential running:-
Hope this helps.
Only one explanation comes to my mind:
If above assumptions are correct JMeter is simply lacking resources in order to kick off that many threads and given JMeter is not capable of sending requests fast enough you're getting "false negative" results as JMeter spends time in GC trying to free up some Heap space in order to be able to operate.
So:
