Jmeter stores its data in an XML file. You can use an XSLT to create a report. We can automate report writing once the requirements are known. Off the top of my head and not very comprehensive. As Jmeter has a wide community it would not surprise me if there are even more complete solutions.
Jenkins can consume the XML reports from Jmeter via a plugin. I have a simple ping example at http://builds.sakaiproject.org:8080/job/jmeter_ping/2593/jmeter/? http://builds.sakaiproject.org:8080/job/jmeter_ping/ The period of the graph depends on how the job is configured. There is a maven plugin for basic report generation as well. See: https://github.com/AlanBerg/SakaiOAE-Open/blob/master/TESTS/jmeter_microbenchmark/pom.xml There is an ant plugin for Jmeter with its own XSLT that generates reports. See: http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/SA/v15/i06/a7.htm And also a Google code project that we can script around : http://code.google.com/p/jmeter-plugins/wiki/JMeterPluginsCMD You can also load in test data back into to Jmeter to review the results. More, no doubt? Alan Berg Group Education and Research Services Central Computer Services University of Amsterdam Alan Berg Group Education and Research Services Central Computer Services University of Amsterdam ________________________________________ From: [email protected] [[email protected]] on behalf of Eli Cochran [[email protected]] Sent: 16 July 2012 14:34 To: Branden Visser Cc: [email protected] Subject: Re: [oae-dev] Load testing tool Brandon, How would you compare the quality of the reports and the ability to customize the reports? I was very disappointed with how hard it was to understand the reports from Tsung. While the data was there I really struggled to make sense of it. Poorly designed, no prioritization, poor layout, etc. And while the charting is OK for a single test run (barely), I really wanted a visual way immediately compare two or more different runs so I could immediately see how performance was trending. The Tsung community needs an information designer and a visual designer to spend a couple of weeks working together on the product. I know it's a geek's tool but I've come to expect better. Perhaps I've been spoiled by the gorgeous reports out of google analytics. Sent via iPhone Please excuse any spelling errors or odd auto-corrections. On Jul 16, 2012, at 7:42 AM, Branden Visser <[email protected]> wrote: > Hi everyone, > > I've been putting some research into an appropriate load testing tool > for us to use, I have been focusing mainly on JMeter and Tsung. > > Tsung, as far as I can tell, has the following selling points: > > 1. Its erlang guts let it drive many concurrent users more efficiently > than its competitors > 2. Its XML structure seems quite leaner, making it easier build tests > from source > 3. There is existing work from rSmart that can be leveraged to drive > our performance tests [1] > > With JMeter, I see the following benefits: > > 1. Lower overhead in spinning up a test, once the tests are already > built (VIA a maven plugin) > 2. I think the increase in complexity of JMeter comes with the benefit > of extensibility (unless you know erlang, I guess..) > 3. There is an existing community effort that can be leveraged to > drive our performance tests [2] > > They both have exactly 3 advantages, I don't know what to do!? > > Just kidding. But, unless there is quantifiable evidence that suggests > JMeter's performance will not suffice to properly test OAE (I have not > been able to find such evidence yet, but others may have more data), I > propose that we move forward with JMeter. I see value in making the > JMeter tests executable from the same command-line on which OAE is > built. I think this moves towards making the JMeter tests an artifact > of the release and not some orthogonal set of scripts uploaded > elsewhere, which in my experience tend to become of questionable age > and relevance. I think it will become more valuable to our deployers, > and the deployers' performance test data (which would hopefully be > more abundant with the lower barrier of entry) will become more > valuable to the core team. > > [1] https://github.com/kcampos/Open-Performance-Automation-Framework > [2] https://confluence.sakaiproject.org/display/QA/CLE+Load+Test+Framework > > -- > Cheers, > Branden > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
