Hi, Documentation is not the solution because a lot of people don't read it
Change JMeter to be more easy to used is the solution And I am ok that "View Results Tree" is needed in both menu with two different config Instead of naming it "Debug Listener" I think it will be greater to mane it "Debug" Antonio Cet e-mail a été envoyé depuis un ordinateur protégé par Avast. www.avast.com <https://www.avast.com/fr-fr/lp-safe-emailing?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=OA-2109-A> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> 2016-03-12 13:53 GMT+01:00 sebb <seb...@gmail.com>: > Seems to me that the way to address the debugging issue is to write > some documentation suggesting how to use the listeners for this > purpose. > And to let people know which Listeners need lots of memory. > > There are perfectly good reasons for having a Tree View Listener in a > Load Test Plan. > e.g. it might be in a branch that is rarely taken. > Remember also that Load Tests should only be done in non-GUI mode. > > I am opposed to thos change; it will cause more problems than it > solves, and is the wrong way to approach the issue. > > > On 11 March 2016 at 21:11, Vladimir Sitnikov > <sitnikov.vladi...@gmail.com> wrote: > > Vladimir> If the only aim of creating a debug listeners menu is to > avoid OOM, > > Philippe>Not only this one. > > > > Can we start from the requirements then? (I might miss the original > email) > > > > Philippe>The use case is "I want to debug my plan" > > > > I think the most surprising thing for newbies is that "listeners are > inherited". > > Implementing pause/resume/breakpoint would be great. > > > > Have you considered creating duplicate entries for "View Results Tree"? > > For instance, display it under current menu and under "debug ..." at > > the same time. > > > > Philippe>I think when you use a View Results Tree even with logs, you are > > trying to debug errors no ? > > > > View Results Tree can: > > 1) "log all results". This is useful for debugging. > > 2) "log errors only". It should skip successfull responses and log > > only erroneous ones (e.g. the ones with failed assertions, etc). > > > > The second option is useful even for regular load testing, as it would > > enable investigation of concurrency issues. > > Number of errors should not be high => number of logged results would > > not be high => no OOM, no much overhead. > > > > Otherwise you would have hard time trying to figure out why test fails > > under load. > > > > Vladimir >
