My first problem was, where this small discussions started, was that distributed testing was not very scalable, the second problem that I very soon discover was that the visualizer (Aggregate Report) where not very scalable for long running tests, after only a few hours it were running out of memory due to the fact that all samples where stored twice in various caluclators to be able to calculate median and 90% 'median'. Scalable Server --------------- This was not very hard at all! First I created a subclass of the SampleSender interface - StatisticalSampleSender, working very much like the BatchSampleSender. The sample sender creates a statistical SampleResult and dispatches those every second or so, configurable as BatchSender (using the same properties). I also had to modify the SampleSenderFactory to create this new sample sender if property mode=Statistical. This works perfectly fine, I have now been running a JMeter cluster of 8 servers and the server -> controller communication is not measurable. This has the limitation that not all the individual sample result were sent back, but for long running test, this is a non-issue, at least for us. Scalable Visualizer ------------------- I found myself using the aggregate report visulizer and graph listener, so I decided to write a scalöable combined visualizer. See the screenshot as attachment. I also wanted to see how the different load servers were doing, so the only core change was to the SampleEvent class had to send the hostname it was running on back to the controller for each sample. The visulaizer does not store each sample it receives, and thus the memory is not growing at all, I have JConsole connected and after 3 days of continous running it was using only 32 MB memory. The graph only stores some limited number of values. This visualizer requires some additional jars from JFreeChart and JNDC. ----------- New component classes in package: org.apache.jmeter.samplers ------------------------------------------------------------ StatisticalSampleSender - A new SamplerSender implementation, based on BatchSamplerSender. StatisticalSampleResult - A new SampleResult subclass Changed component classes in package: org.apache.jmeter.samplers ---------------------------------------------------------------- SampleEvent - New field hostname SampleSenderFactory - New mode='Statistical' to chose the new StatisticalSampleSender New visulaizer i n package se.six.jmeter.visualizers.statagg (should propablbly be refactored to org.apache.jmeter.visualizers.statagg. All classes are new and not enumerated, these are all new additions that does not affect any other visualizer. BUT required that JFreeChart and JNDC are installed.
Created attachment 16745 [details] Sceenshot of new visualizer
Created attachment 16746 [details] Dependent JFreeChart jar
Created attachment 16747 [details] Dependent JFreeChart jar (JCommon)
Created attachment 16748 [details] Dependent JNDC jar
Created attachment 16749 [details] Java sources for new visualizer
Created attachment 16750 [details] Java source, changes to core classes.
I've checked in the code in the core package. I made some minor changes and added the necessary method SampleResult, so the new class can use it easier. I also added your name to the contributors page. peter lin
Do you know of alternative/additional TreeTable model implementations? Java desktop isn't open source, or atleast I don't think it is. I would rather not write a new TreeTable model if I don't have to. there's got to be an open source implementation of TreeTableModel. I found this old article from 97/98 http://java.sun.com/products/jfc/tsc/articles/treetable1/ it's easy enough to write a new one, but I'd rather not re-invent the wheel if I don't have to. peter lin
Hello, It is indeed open source, https://jdnc.dev.java.net/ it is released under LGPL licenese, and so is the JFreeChart package: http://www.jfree.org regards Lars Krog-Jensen (In reply to comment #11) > Do you know of alternative/additional TreeTable model implementations? Java > desktop isn't open source, or atleast I don't think it is. I would rather not > write a new TreeTable model if I don't have to. there's got to be an open > source implementation of TreeTableModel. I found this old article from 97/98 > http://java.sun.com/products/jfc/tsc/articles/treetable1/ > it's easy enough to write a new one, but I'd rather not re-invent the wheel if > I don't have to. > peter lin
For some reason, deskzilla resent previous comments when I started it up. Ignore the duplicate. I'm working on writing a clean implementation of TreeTableModel, since Apache doesn't allow LGPL code. peter
I'm working on an implementation of TreeTableModel that is similar to our ObjectTableModel. Have to figure out how ObjectTableModel works, so it will be a few weeks, unless mike helps :) peter
Hello, Wow, I really do not understand these license issues, but I though LGPL was very, very open. I guess that implmenting a TreeTableModel is not very easy, nor is it easy to write the JXTreeTable swing component. The JFreeChart component is also LGPL, so I guess that would have to be replaced aswell. All this rewrtiting seems to me to be so meaningless work, there are great components out there available for free and OS, but again, I am no layer. Wouldn't it be better to include only the core changes and leave out the new visualizer and provide it as a sepearate plugin download, for those that do not have an issue with LGPL. regards Lars Krog-Jensen
Hi lars, I've already committed the core changes. you can see in the latest subversion for 2.1 branch. that was checked in 2 weeks back. unforunately, apache policy is apache policy. it does seem like redundant work, but I try to avoid the political issues as much as possible and focus on coding. thanks again for your contributions. I'm slowly working on treetable and replacing JFreeChart with JCharts. peter
Note that the latest version of the 2.1 source now has a Summary Report. This is much the same as the Aggregate Report, except that the Median and 90% columns have been removed, so there is no longer any need to store all the samples. [Data is now only saved for each line in the report, rather than each sample.]
old issue, many solutions have been provided since then: - Different implementations of SampleSender - Aggregate graphs
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/1627