Alan thanks for the response. I'm adding oae-production to this conversation.
...... ..... .... ... .. . . . . . . . . .
. .
Eli Cochran
Project Manager, CalCentral Project
Educational Technology Services, UC Berkeley
On Jul 16, 2012, at 9:02 AM, "Berg, Alan" <[email protected]> wrote:
> 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
