You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Yngvi Þór Sigurjónsson <bl...@gmail.com> on 2014/12/05 22:59:06 UTC

JDBC Sampler stores variables as Strings

Hi
I'm new to JMeter, what I want to do is to do load testing on some Oracle
database applications. Using the JDBC Sampler I have run into a little snag
with the way variables are stored as strings after the JDBC request to Callable
Statement.

In Oracle it is a common practice to return queries from stored procedures
as a construct called refcursor. Refcursors are then returned as ResultSets
to Java and if you really want to do thorough load test you actually have
to loop through the whole result set.  This would be simple to do with a
JSR223 sampler following the JDBC sampler if it was not for the fact that
the JDBC sampler stores the ResultSet object as a string.

Fixing this is actually a single line edit of the file
AbstractJDBCTestElement.java line 256 to:
jmvars.putObject(name, o);
instead of:
 jmvars.put(name, o == null ? null : o.toString());

Does anyone know if there is a good reason for this toString, or if It
could be fixed in the official source?

I'm ready to provide any further information and a working sample if
requested.

Regards
Yngvi

Re: JDBC Sampler stores variables as Strings

Posted by sebb <se...@gmail.com>.
On 6 December 2014 at 00:33, Yngvi Þór Sigurjónsson <bl...@gmail.com> wrote:
> On Fri Dec 05 2014 at 10:46:54 PM sebb <se...@gmail.com> wrote:
>
>>
>> There are ways round this:
>> - provide a way to select Object storage for all variables. However
>> this would be a nuisance if the variable is not a RefCursor
>> - provide a way to select Object storage specific variable names
>> - provide a way to select Object storage for specific variable types
>> (e.g. all RefCursor types)
>>
>> It's vital that any such change is optional, and does not change the
>> existing behaviour.
>>
>>  Hi
> Thank you for a fast response, I understand your concerns.
> I would like to propose the fourth solution:
> Instead of messing with the variable stored in jmvars we could in the
> output part, check if a variable is a ResultSet and if it is we loop
> through it and output the count of records.

I did wonder about that as well ...

> I believe that this would benefit everyone because it would actually
> generate the full load of the request, now it is only generating load for
> the first rows. And the user (me :)) does not have to do any additional
> scripting beyond calling the stored procedure to loop through the cursor.

This will change the behaviour of the sampler, and may not be wanted
by everyone, so I think this needs to be optional as well.

> In my experience with optimizing Oracle performance there can be a
> significant difference between starting a query and  actually finish
> reading through it. This is often overlooked when timing and tracing stored
> procedure calls that return refcursors.
>
> Something like this works for me (providing gmail does not mess it up) :
> Index:
> src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/AbstractJDBCTestElement.java
> ===================================================================
> ---
> src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/AbstractJDBCTestElement.java
> (revision
> 1643442)
> +++
> src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/AbstractJDBCTestElement.java
> (working
> copy)
> @@ -242,6 +242,12 @@
>                      sb.append(i+1);
>                      sb.append("] ");
>                      sb.append(o);
> +                    if( o instanceof java.sql.ResultSet ) {
> +                        int j=0;
> +                        while(((java.sql.ResultSet)o).next())
> +                            j++;
> +                        sb.append(" "+j+" rows");
> +                    }
>                      sb.append("\n");
>                  }
>              }

For tracking patches we use Bugzilla.

http://jmeter.apache.org/issues.html

Please create a login, raise an enhancment issue and attach any patches there.

> Regards
> Yngvi

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org


Re: JDBC Sampler stores variables as Strings

Posted by Yngvi Þór Sigurjónsson <bl...@gmail.com>.
On Fri Dec 05 2014 at 10:46:54 PM sebb <se...@gmail.com> wrote:

>
> There are ways round this:
> - provide a way to select Object storage for all variables. However
> this would be a nuisance if the variable is not a RefCursor
> - provide a way to select Object storage specific variable names
> - provide a way to select Object storage for specific variable types
> (e.g. all RefCursor types)
>
> It's vital that any such change is optional, and does not change the
> existing behaviour.
>
>  Hi
Thank you for a fast response, I understand your concerns.
I would like to propose the fourth solution:
Instead of messing with the variable stored in jmvars we could in the
output part, check if a variable is a ResultSet and if it is we loop
through it and output the count of records.

I believe that this would benefit everyone because it would actually
generate the full load of the request, now it is only generating load for
the first rows. And the user (me :)) does not have to do any additional
scripting beyond calling the stored procedure to loop through the cursor.

In my experience with optimizing Oracle performance there can be a
significant difference between starting a query and  actually finish
reading through it. This is often overlooked when timing and tracing stored
procedure calls that return refcursors.

Something like this works for me (providing gmail does not mess it up) :
Index:
src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/AbstractJDBCTestElement.java
===================================================================
---
src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/AbstractJDBCTestElement.java
(revision
1643442)
+++
src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/AbstractJDBCTestElement.java
(working
copy)
@@ -242,6 +242,12 @@
                     sb.append(i+1);
                     sb.append("] ");
                     sb.append(o);
+                    if( o instanceof java.sql.ResultSet ) {
+                        int j=0;
+                        while(((java.sql.ResultSet)o).next())
+                            j++;
+                        sb.append(" "+j+" rows");
+                    }
                     sb.append("\n");
                 }
             }

Regards
Yngvi

Re: JDBC Sampler stores variables as Strings

Posted by sebb <se...@gmail.com>.
On 5 December 2014 at 21:59, Yngvi Þór Sigurjónsson <bl...@gmail.com> wrote:
> Hi
> I'm new to JMeter, what I want to do is to do load testing on some Oracle
> database applications. Using the JDBC Sampler I have run into a little snag
> with the way variables are stored as strings after the JDBC request to Callable
> Statement.
>
> In Oracle it is a common practice to return queries from stored procedures
> as a construct called refcursor. Refcursors are then returned as ResultSets
> to Java and if you really want to do thorough load test you actually have
> to loop through the whole result set.  This would be simple to do with a
> JSR223 sampler following the JDBC sampler if it was not for the fact that
> the JDBC sampler stores the ResultSet object as a string.
>
> Fixing this is actually a single line edit of the file
> AbstractJDBCTestElement.java line 256 to:
> jmvars.putObject(name, o);
> instead of:
>  jmvars.put(name, o == null ? null : o.toString());
>
> Does anyone know if there is a good reason for this toString, or if It
> could be fixed in the official source?

JMeter variables can store arbitrary objects, but mostly JMeter
assumes that variables contain Strings.
There's no in-built way to use variables unless they are Strings, but
as you noted they can be accessed in user code, for example in a
JSR-223 or BeanShell test element.

It would break existing test plans if JDBC were changed as you suggest.

There are ways round this:
- provide a way to select Object storage for all variables. However
this would be a nuisance if the variable is not a RefCursor
- provide a way to select Object storage specific variable names
- provide a way to select Object storage for specific variable types
(e.g. all RefCursor types)

It's vital that any such change is optional, and does not change the
existing behaviour.

> I'm ready to provide any further information and a working sample if
> requested.

> Regards
> Yngvi

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org