Le 12/09/2010 13:04, sebb a ecrit :
> On 10 September 2010 17:20, Milamber <[email protected]> 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)
Ex: SELECT ID, NAME, DATA1, etc FROM MY_TABLE WHERE ID_CLIENT =
${MY_PROPERTIE}
Milamber
>> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>>
> ---------------------------------------------------------------------
> 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]
