https://bz.apache.org/bugzilla/show_bug.cgi?id=64118
Felix Schumacher <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO --- Comment #6 from Felix Schumacher <[email protected]> --- Could you attach a sample JTL file, that you use for the reports? I think the problem is, that the processing logic looks at the number of threads reported by each worker node. Those nodes have no knowledge of the number of active threads on the other nodes and therefore report the number of active local threads. The "Active threads vs time graph" groups by timestamp (which is the same on each worker node and can be used without problem). The grouped data splits on the thread name (which can be done, as it is unique among the cluster). This results in a correct reporting. The "Response time vs thread graph" groups on the number of threads reported by the worker nodes (which is the number of local threads). As we have no knowledge of the timestamp (at least in the current implementation) and no knowledge of the other worker nodes state, these numbers are incorrect when seen from a global point of view. I am not sure, how we can tackle this problem without introducing either uncertainty (by using assumptions, for example that every worker node has the same number of active threads at that point in time) or by combining the knowledge extracted from "Active threads vs time graph" and using it to interpolate the number of threads (doesn't work well with the current implementation). -- You are receiving this mail because: You are the assignee for the bug.
