jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: REPOST: Adding an option to output results to a db? (not csv or xml.)
Date Wed, 01 Feb 2012 20:30:14 GMT
Note that there is an issue in Bugzilla for it with attached patch:

   - https://issues.apache.org/bugzilla/show_bug.cgi?id=31666


I looked 2 month ago at code and part of it can be reused although it needs
some rework as patch is old.

I agree with Sebb on the performance impact:

   - if db is remote then latency  and network used bandwidth can disturb
   the results
   - if db is local (hsqldb, sqlite ...) then it could impact injector and
   would only apply with non distributed test + limits on number of rows of
   these databases ?


But this could be useful for people who use JMeter for functional testing.

Regards

Philippe

On Wed, Feb 1, 2012 at 9:20 PM, sebb <sebbaz@gmail.com> wrote:

> On 1 February 2012 19:35, Oliver Lloyd <oliver_lloyd@hotmail.com> wrote:
> > This is an old one, I know, but it's something we really want from this
> tool
> > (the advantages are clear) and we've actually already got a vaguely
> working
> > prototype in place so I wanted to raise it here to see if anyone had
> > experience with this that we could learn from before going deeper?
>
> The disadvantage is that writing large numbers of  samples to a
> database is likely to be slower than writing to a file.
> This would impact the maximum sample rate that JMeter can sustain.
>
> The minimum load on JMeter is likely to be using CSV to a file
> followed by off-line upload.
> However, for long-running tests that don't approach the maximum
> database write rate, it would mean that data was available much sooner
> in the database.
>
> > Essentially, the end goal is to allow the user to specify 'db' in place
> of
> > 'csv' or 'xml' in the properties file - so long as valid connection
> details
> > are given - and then JMeter would no longer use the jtl format but insert
> > into a table.
> >
> > The problem as I see it is is that the listeners rely on the jtl format
> to
> > work so if you redirect output to a new datasource then the listeners
> will
> > no longer work so you're forced to create a new presentation layer. Any
> > thoughts?
>
> What makes you think that Listeners depend on the output format?
> They still work even if there is no output; the samples are saved
> after they have been sent to the Listeners.
>
> The code to write and read from JTL files is common to all Listeners,
> so adding DB support should not involve changing any presentation
> layer.
>
> The Listener config
>
> http://jmeter.apache.org/usermanual/listeners.html#sample_configuration
>
> would need to be extended to support database output, unless we extend
> the file name field to allow jdbc URLs.
>
> I think most of the rest of the config still applies to JDBC output,
> i.e. it should be possible to use the config to select which fields to
> save.
>
> >
> > @apc My hope is that synchronous db inserts would perform much better on
> a
> > db vs. a file. Plus the advantages of having results stored in a db vs.
> lots
> > of separate text files are huge.
> >
> >
> > PS. Apologies, this post belongs in the dev forum but my subscription
> > failed...
> >
> > -----
> > http://www.http503.com/
> > --
> > View this message in context:
> http://jmeter.512774.n5.nabble.com/REPOST-Adding-an-option-to-output-results-to-a-db-not-csv-or-xml-tp5448528p5448528.html
> > Sent from the JMeter - User mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> > For additional commands, e-mail: user-help@jmeter.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message