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 <[email protected]> wrote: > On 1 February 2012 19:35, Oliver Lloyd <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cordialement. Philippe Mouawad.
