search

apache / jmeter

Apache JMeter open-source load testing tool for analyzing and measuring the performance of a variety of services
https://jmeter.apache.org/
Apache License 2.0
8.43k stars 2.11k forks source link

Add JDBC pre- and post-processor #2634

Closed asfimport closed 12 years ago

asfimport commented 13 years ago

Roman Bargezi (Bug 52128): Add support for a JDBC PreProcessor and PostProcessor.

I often need to setup things before the actual measuring. Like creating a table (pre-process), then sample filling in some data and finally dropping the table (post-process). Or I need to clear the caches on the DB (pre-process/post-process).

I could do all of this using the JDBC Request sampler, but it polutes my listeners with results I don't want in the final output. Thus this request.

Version: Nightly OS: All

asfimport commented 13 years ago

Roman Bargezi (migrated from Bugzilla): As this is a major refactoring, please let me know if this is going in the right direction for you to accept. I will then clean up, add docs, etc. and submit a final proposal.

Created attachment Enh52128_AddJdbcPreAndPostProcessor.patch: Directional Patch proposal for Jdbc Pre And Post Processor against build 1196526

asfimport commented 13 years ago

Sebb (migrated from Bugzilla): Sounds like a job for the setUp and tearDown thread groups.

Have you tried those?

asfimport commented 13 years ago

Roman Bargezi (migrated from Bugzilla): (In reply to comment 2)

Sounds like a job for the setUp and tearDown thread groups.

Have you tried those?

I can't quite see how they can solve my case. Two things I would like to note here:

  1. If I use the setup- and tear-down threads, I still get the results of the samples in those threads collected by my listeners. So even in this case I get garbage.

  2. I have a testcase where one thread group runs more than one loop (in my case 3). Before each loop starts sampling, I have to reset a field in a DB table. After I have sampled my JDBC test requests, I need to cleanup the data that was created by the sample. All I want to collect is the timings of the JDMC test request. If I use the setup and tear-down threads, the call is only made once before the 3 loops are executed and after all 3 loops have ended. Thus having a JDBC pre- and post-processor would be nice. So far I have used the BSF porcessors with some groovy, but this is not convenient if you have pure SQL testers.

asfimport commented 13 years ago

Sebb (migrated from Bugzilla): (In reply to comment 3)

(In reply to comment 2) > Sounds like a job for the setUp and tearDown thread groups. > > Have you tried those?

I can't quite see how they can solve my case. Two things I would like to note here:

  1. If I use the setup- and tear-down threads, I still get the results of the samples in those threads collected by my listeners. So even in this case I get garbage.

That depends where you put the Listeners.

  1. I have a testcase where one thread group runs more than one loop (in my case 3). Before each loop starts sampling, I have to reset a field in a DB table. After I have sampled my JDBC test requests, I need to cleanup the data that was created by the sample. All I want to collect is the timings of the JDMC test request. If I use the setup and tear-down threads, the call is only made once before the 3 loops are executed and after all 3 loops have ended. Thus having a JDBC pre- and post-processor would be nice. So far I have used the BSF porcessors with some groovy, but this is not convenient if you have pure SQL testers.

Again, you can do this by careful placement of the Listeners.

Also, Pre- and Post-Processors are intended for use before/after each sample; the use-case here seems rather different.

Although it is possible to adjust the positioning of the listeners, that can become tedious, so another possibility is to add an option to the JDBC Sampler so it returns a null sample (the Test Action Sampler does this). It should probably only nullify the result if successful.

asfimport commented 13 years ago

Roman Bargezi (migrated from Bugzilla): (In reply to comment 4)

(In reply to comment 3) > (In reply to comment 2) > > Sounds like a job for the setUp and tearDown thread groups. > > > > Have you tried those? > > I can't quite see how they can solve my case. Two things I would like to note > here: > 1. If I use the setup- and tear-down threads, I still get the results of the > samples in those threads collected by my listeners. So even in this case I get > garbage.

That depends where you put the Listeners.

> 2. I have a testcase where one thread group runs more than one loop (in my case > 3). Before each loop starts sampling, I have to reset a field in a DB table. > After I have sampled my JDBC test requests, I need to cleanup the data that was > created by the sample. All I want to collect is the timings of the JDMC test > request. If I use the setup and tear-down threads, the call is only made once > before the 3 loops are executed and after all 3 loops have ended. Thus having a > JDBC pre- and post-processor would be nice. So far I have used the BSF > porcessors with some groovy, but this is not convenient if you have pure SQL > testers.

Again, you can do this by careful placement of the Listeners.

Also, Pre- and Post-Processors are intended for use before/after each sample; the use-case here seems rather different.

Although it is possible to adjust the positioning of the listeners, that can become tedious, so another possibility is to add an option to the JDBC Sampler so it returns a null sample (the Test Action Sampler does this). It should probably only nullify the result if successful.

Maybe I was not clear enough with my usecase description. My usecase is exactly that I need to pre-/post-process an individual sample. Thus I have so far placed the BSF Pre/Post processors with some SQL code before and after my JDBC Sampler to achieve my goal. In other cases I even have more than one JDBC sample I take in a single thread and need to pre-process and post-process individual samples.

I did a quick test with returning a null sample result from the JDBC sample and it works. I just don't like the solution approach as it is more of a workaround and does not read properly (the user does not really see that things arepre/post-processed). I thus still think adding the JDBC pre/post-processors is the more elegant solution to the problem.

asfimport commented 13 years ago

Sebb (migrated from Bugzilla): OK, I understand now - that makes more sense.

I notice that the patch includes the following import:

import ch.infonic.jmeter.jdbc.JDBCSamplerDiagnosticListener;

I assume this is not relevant to this issue?

Otherwise the patch looks reasonable.

asfimport commented 13 years ago

Roman Bargezi (migrated from Bugzilla): Added final patch proposal w/o the diagnostic listener mentioned by Sebb

Created attachment Enh52128_AddJdbcPreAndPostProcessor.patch: Patch proposal for Jdbc Pre And Post Processor against build 1196526

asfimport commented 13 years ago

Roman Bargezi (migrated from Bugzilla): Sebb, assuming you may now consider the enhancement I have added my final proposal. I am happy to update the Docs/Manual as well. As I don't quite know how, please let me know where I have to edit things and where you would want an upload.

asfimport commented 13 years ago

Roman Bargezi (migrated from Bugzilla): Created attachment Enh52128_AddJdbcPreAndPostProcessor.patch: Patch proposal for Jdbc Pre And Post Processor against build 1196526

asfimport commented 13 years ago

Roman Bargezi (migrated from Bugzilla): Fixed some issues with resources.

SEBB YOU MAY WANT TO CHECK THIS:

This really drives me nuts! Maybe you have an answer to this inexplicable behavior. Or is it just a bug?

Created attachment Enh52128_AddJdbcPreAndPostProcessor.patch: Patch proposal for Jdbc Pre And Post Processor against build 1196526

asfimport commented 13 years ago

Sebb (migrated from Bugzilla): (In reply to comment 10)

Created attachment 27901 [details] Patch proposal for Jdbc Pre And Post Processor against build 1196526

Fixed some issues with resources.

SEBB YOU MAY WANT TO CHECK THIS:

  • In trying not to duplicate resources, I added a base resource for the AbstractJDBCTestElement
  • I then only added the 'displayName' to the additional resource files (JDBCPostProcessorResources.properties and JDBCPreProcessorResources.properties)
  • The property labels worked fine but THE GROUP LABELS WERE NOT THERE!
  • So I added the group labels to the Processor resources and all was good
  • Then I did the same for JDBCSamplerResources.properties
  • NOW THE PROPERTY LABELS WERE GONE FOR THIS BEAN!

This really drives me nuts! Maybe you have an answer to this inexplicable behavior. Or is it just a bug?

I noticed some odd behaviour with the TestBean property handling some while ago. Never got to the bottom of it - not sure if it is a JMeter bug or a JavaBeans limitation.

The only existing BeanInfoSupport class hierarchies are the BeanShell and BSF/JSR223 trees, which have a common parent class and don't add any customisation in the subclasses - maybe that is why they work.

Hopefully we can sort out the behaviour once the main code is incorporated.

asfimport commented 13 years ago

Sebb (migrated from Bugzilla): Thanks, applied.

Inheritance does not seem to work for TestBean properties files, so I just copied the common fields to the Pre and Post processor properties, and dropped the common parent.

Seems to work.

URL: http://svn.apache.org/viewvc?rev=1197848&view=rev Log: https://github.com/apache/jmeter/issues/2634 - Add JDBC pre- and post-processor

Added: jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/AbstractJDBCTestElement.java (with props) jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/JDBCTestElementBeanInfoSupport.java (with props) jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/processor/ jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/processor/AbstractJDBCProcessor.java (with props) jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/processor/JDBCPostProcessor.java (with props) jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/processor/JDBCPostProcessorBeanInfo.java (with props) jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/processor/JDBCPostProcessorResources.properties (with props) jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/processor/JDBCPreProcessor.java (with props) jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/processor/JDBCPreProcessorBeanInfo.java (with props) jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/processor/JDBCPreProcessorResources.properties (with props) Modified: jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/sampler/JDBCSampler.java jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/sampler/JDBCSamplerBeanInfo.java jmeter/trunk/xdocs/changes.xml

asfimport commented 13 years ago

Sebb (migrated from Bugzilla): (In reply to comment 8)

Sebb, assuming you may now consider the enhancement I have added my final proposal. I am happy to update the Docs/Manual as well. As I don't quite know how, please let me know where I have to edit things and where you would want an upload.

The documentation is in the file

xdocs/usermanual/component_reference.xml

You just need to add the appropriate <component> paragraphs to the end of the relevant sections.

Patch can be provided as for code patches.

Screenshots can be generated using ^G if you want to do those; if not I can add them later. If you have some useful (publishable) examples of SQL code that can be used in the pre/post processors that would be very good - either provide screenshots, or a test plan with the fields filled in, and we can the do the screenshots.

asfimport commented 13 years ago

Sebb (migrated from Bugzilla): Could you provide some examples for the documentation please?

asfimport commented 13 years ago

Roman Bargezi (migrated from Bugzilla): Sebb,

I thought hard about some fictitious sample, but could not come up with something that makes sense. So I have attached a sample from our real world. What it does is it measures the execution for parallel runs of a multi-portfolio valuation.

What needs to be done in preparation is:

Then we run the actual calculation and sample it

The post-processor then does the cleanup by deleting the results and the PCO

Hope this helps. I'll be off-line for the next 2 weeks, but please let me know if you need anything more. I'll follow up once I am online again.

Created attachment MI_DailyNAV_Test2.jmx: Example using JDBC pre and post processors

asfimport commented 12 years ago

@pmouawad (migrated from Bugzilla): Date: Fri Dec 2 21:34:56 2011 New Revision: 1209701

URL: http://svn.apache.org/viewvc?rev=1209701&view=rev Log: https://github.com/apache/jmeter/issues/2634 - Add JDBC pre- and post-processor

Modified: jmeter/trunk/xdocs/usermanual/component_reference.xml