jakarta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <milam...@apache.org>
Subject Re: [JMeter] Extending JMeter: Shared Data Set
Date Sun, 12 Sep 2010 15:00:20 GMT

Le 12/09/2010 13:04, sebb a ecrit :
> On 10 September 2010 17:20, Milamber <milamber@apache.org> wrote:
>> Hello,
>> Your idea is good, and(but) needs a lot of works.
>> Please note, you can do this with another way:
>> 1/ use a JDBC sampler with a SQL SELECT on a database, around a Once
>> only controller which start first in test
>> 2/ and JMeter's function __V{}
>> http://jakarta.apache.org/jmeter/usermanual/functions.html#__V
>> to build dynamically variables name from SELECT results.
>> This way is limited by JVM memory (all rows are store in memory by JDBC
>> SELECT request), but for a small list (<10.000 rows) this is a good way.
>> I wrote a french tutorial in 2 parts to do this.
>> http://blog.milamberspace.net/index.php/2009/06/12/jmeter-utilisation-de-lelement-jdbc-comme-source-de-donnees-pour-un-test-de-charge-partie-1-311.html
>> http://blog.milamberspace.net/index.php/2009/06/13/jmeter-utilisation-de-lelement-jdbc-comme-source-de-donnees-pour-un-test-de-charge-partie-2-317.html
>> (sorry, it's in french, but some screen-shots shows the way)
> I'm not sure that will work in client-server mode, because each server
> will run the same JDBC query.

With a Jmeter properties and SQL query with parameter to select data for
each client, that will works (not tested)



>> Milamber
>> Le 09/09/2010 12:05, Jens Müller a ecrit :
>>> Hello,
>>> JMeter does not seem to include a test element that allows a string out of a
list to be assinged to a variable, guaranteeing at most once semantics for all users, even
in distributed mode. Meaning that every element of the list will only be used once, even trhoughout
multiple test runs.
>>> I have the following in mind:
>>> Creating a ConfigTestElement (currently a TestBean) which allows the user to
add a list of values. When starting the test, this list would be put into a centrally accessible
singleton and everytime a value would be read in iterationStart, it would be removed from
this central list and assigned to a variable, similarly to CSV Data Set Config, only that
the value is not read from a file.
>>> So far possible.
>>> When the test is completed, only the remaining unused values should be present
in the test element. How can I modify a specific element in the test tree? If I implement
TestListener and change the list in testEnded, this change is not applied to the test element
if I open it in the test plan. It is probably cloned, but even by overriding clone and keeping
a reference to the original element, I cannot get the test element's values changes.
>>> Furthermore, in distributed mode, I would need to split the list in equal parts
to the different client hosts. This could be done somewhere in ClientJMeterEngine#Configure,
not cloning the element, but taking a sublist of the complete list. The total number of hosts
and the number of the current host would need to be known for this. These two values could
be filled into some context in RemoteStart#doAction.
>>> Every host would then perform its test run and at the end, they would need to
send back the sublist of unused items. As far as I understand, only the Listeners are wrapped
with RemoteListenerWrapper so that they can transfer back information. Maybe the information
which elements of the list were not used can be piggybacked somewhere on testEnded? The compund
list of remaining items would then again need to be incorporated into the original test element
- a problem I already described above.
>>> Any help in solving any of these sub tasks is very appreciated.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org

To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

View raw message