You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Furash Gary <fu...@mcao.maricopa.gov> on 2006/02/16 17:13:04 UTC
How to use previously defined JDBC information
If I have previously defined JDBC connection information in a step, and
in a subsequent step (java or beanshell) I want to use that connection
that JMeter has created, how do I access it. I'm sure it's an object
residing in the flow but I'm not sure how to get at it.
Gary Furash, MBA, PMP, Applications Manager
Maricopa County Attorney's Office
Re: How to use previously defined JDBC information
Posted by sebb <se...@gmail.com>.
Check the code ;-)
Why would you need to access it?
Can you not use the JDBC sampler?
If you do find out how to do this, be aware that the internal workings
of the JDBC sampler may change ...
S.
On 16/02/06, Furash Gary <fu...@mcao.maricopa.gov> wrote:
> If I have previously defined JDBC connection information in a step, and
> in a subsequent step (java or beanshell) I want to use that connection
> that JMeter has created, how do I access it. I'm sure it's an object
> residing in the flow but I'm not sure how to get at it.
>
> Gary Furash, MBA, PMP, Applications Manager
> Maricopa County Attorney's Office
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: How to use previously defined JDBC information
Posted by sebb <se...@gmail.com>.
On 17/02/06, Richard Gaywood <ri...@gmail.com> wrote:
> On 2/16/06, sebb <se...@gmail.com> wrote:
> >
> > On 16/02/06, Richard Gaywood <ri...@gmail.com> wrote:
> > > If you are planning on using JMeter to test stored procedures, you
> > should
> > > read
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=38682
> > > first. This bit me in the past quite badly.
> >
> > Why does the server recompile the stored procedure for executeQuery,
> > and not prepareCall?
> > I'd only expect the SP to be compiled once when it is initially created.
>
>
> Me too, actually, but I'm no DBA. I know our senior DBA here recolied in
> horror when he looked through the SQL Profiler and saw all the calls. I've
> actually seen this in effect: with standard JMeter, the recompiles/sec
> counter in perfmon.msc on the database server was through the roof. With a
> special hacked version I produced which hard-codes prepareStatement() to
> call the SP we were testing, it was zero.
>
> In any event, prepareStatement() offers performance advantages as it passes
> the SQL server parameters of known types and doesn't make it do the parsing
> donkey work.
>
> More details here:
> http://www-db.stanford.edu/~ullman/fcdb/oracle/or-jdbc.html#0.1_prepare
>
> Reading that now makes it sound like the recompile actually *is* parsing the
> incoming SQL, rather than compiling the SP itself. That makes more sense,
> actually.
Yes.
> Seems like a limitation in MS SQL server rather than JMeter ...
>
Not really a limitation - what else can it do if the SQL may change?
>
> I'm informed it also effects Oracle, although I haven't seen this with my
> own eyes. Reading the link above suggests it would effect all DBMSs.
It affects Ingres - in the embedded SQL language there is a REPEATED
keyword which is used to tell the pre-processor to generate a prepared
statement.
This needs to be used judiciously, as the prepared statements require
storage. Also any optimisation is only done once, with the initial set
of values. So for some data distributions you may be unlucky and get a
bad query plan.
But I agree it would be useful to be able to use prepared statements in JMeter.
This could be done as in Ingres, which just "names" the prepared
statement according to its position in the source file [and the file
name].
JMeter could perhaps use a checksum of the query text to identify the
SQL. This would allow them to be shared across threads. This is
similar to the behaviour in Ingres, where multiple processes running
the same code will use the same plan.
Or perhaps we need a statement pool, with names provided by the user,
like the connection pool.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: How to use previously defined JDBC information
Posted by Richard Gaywood <ri...@gmail.com>.
On 2/16/06, sebb <se...@gmail.com> wrote:
>
> On 16/02/06, Richard Gaywood <ri...@gmail.com> wrote:
> > If you are planning on using JMeter to test stored procedures, you
> should
> > read
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=38682
> > first. This bit me in the past quite badly.
>
> Why does the server recompile the stored procedure for executeQuery,
> and not prepareCall?
> I'd only expect the SP to be compiled once when it is initially created.
Me too, actually, but I'm no DBA. I know our senior DBA here recolied in
horror when he looked through the SQL Profiler and saw all the calls. I've
actually seen this in effect: with standard JMeter, the recompiles/sec
counter in perfmon.msc on the database server was through the roof. With a
special hacked version I produced which hard-codes prepareStatement() to
call the SP we were testing, it was zero.
In any event, prepareStatement() offers performance advantages as it passes
the SQL server parameters of known types and doesn't make it do the parsing
donkey work.
More details here:
http://www-db.stanford.edu/~ullman/fcdb/oracle/or-jdbc.html#0.1_prepare
Reading that now makes it sound like the recompile actually *is* parsing the
incoming SQL, rather than compiling the SP itself. That makes more sense,
actually.
Seems like a limitation in MS SQL server rather than JMeter ...
I'm informed it also effects Oracle, although I haven't seen this with my
own eyes. Reading the link above suggests it would effect all DBMSs.
Re: How to use previously defined JDBC information
Posted by sebb <se...@gmail.com>.
On 16/02/06, Richard Gaywood <ri...@gmail.com> wrote:
> On 2/16/06, Furash Gary <fu...@mcao.maricopa.gov> wrote:
> >
> > If I have previously defined JDBC connection information in a step, and
> > in a subsequent step (java or beanshell) I want to use that connection
> > that JMeter has created, how do I access it. I'm sure it's an object
> > residing in the flow but I'm not sure how to get at it.
>
>
> If I understand your problem correctly, you are asking how you link a JDBC
> Connection Configuration compenent to a JDBC Sampler component? If so, what
> you have to do is set "Variable Name Bound to Pool" for the both components
> to the same value. JMeter will then figure it out.
>
> If you are planning on using JMeter to test stored procedures, you should
> read
> http://issues.apache.org/bugzilla/show_bug.cgi?id=38682
> first. This bit me in the past quite badly.
>
Why does the server recompile the stored procedure for executeQuery,
and not prepareCall?
I'd only expect the SP to be compiled once when it is initially created.
If the server runs out of dynamic memory, it may have to drop some
older objects, but that is a bit different.
Seems like a limitation in MS SQL server rather than JMeter ...
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: How to use previously defined JDBC information
Posted by Richard Gaywood <ri...@gmail.com>.
On 2/16/06, Furash Gary <fu...@mcao.maricopa.gov> wrote:
>
> If I have previously defined JDBC connection information in a step, and
> in a subsequent step (java or beanshell) I want to use that connection
> that JMeter has created, how do I access it. I'm sure it's an object
> residing in the flow but I'm not sure how to get at it.
If I understand your problem correctly, you are asking how you link a JDBC
Connection Configuration compenent to a JDBC Sampler component? If so, what
you have to do is set "Variable Name Bound to Pool" for the both components
to the same value. JMeter will then figure it out.
If you are planning on using JMeter to test stored procedures, you should
read
http://issues.apache.org/bugzilla/show_bug.cgi?id=38682
first. This bit me in the past quite badly.