You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Andy Kappen <ak...@gmail.com> on 2005/06/06 19:40:55 UTC
Distributed Testing and Properties
I've inherited some jmeter performance tests, and I have hit a snag
running one of them in distributed mode. The test in question works
fine in non-distributed mode. It uses properties in an external file
to drive dynamic portions of the test (number of threads/loops,
appserver name, appserver port, etc.). These properties are added to
the jmeter runtime environment by using the -p option to jmeter:
jmeter -t target_test.jmx -p devtest_100x5.properties
The test then uses ${__property(prop.name)} to pull values from
'devtest_100x5.properties' into the test. This is a very nice
technique since I can leave the jmx test definitions untouched while
enabling different levels of stress testing against differing
environments just by choosing among a handful of canned property
files. (For me it is easier and less error-prone to edit a property
file than to open the jmeter gui and click a bunch of widgets.)
Now for my question: When I attempt to run this test in a distributed
mode, none of the properties in 'devtest_100x5.properties' are
available to the slave jmeter-server instances. I had hoped that
either (1) all known properties on the jmeter master got pushed down
to the slave (it appears the jmx files are pushed this way) or (2) the
jmeter master would perform the property substitution before pushing
the jmx file to the slaves. For the record, a hardcoded version of
the test (without the property substitution) worked fine in
distributed mode.
Am I heading down a dead-end road here? It's starting to look like
the property file usage of the original test breaks some fundamental
assumptions of jmeter. Will I be stuck writing N statically-defined
jmx files to cover the cross-product of thread/loop/server/port/etc
possibilities?
Thanks for reading, and I hope somebody can come up with an answer.
Cheers,
AK
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
RE Distributed Testing and Properties
Posted by je...@bnf.fr.
I had the same kind of problem with csv file containing my datas. I copied
the file in the slave machines and it worked.
Have you try to copy your properties file to the bin directory of your
slave machines?
Cheers,
Jerome
|---------->
| |
| |
| |
| |
| |
| |
| |
| |
| |
|---------->
>------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| |
| |
|Message de Andy Kappen le 06/06/2005 19:40 |
| |
| |
| |
| |
| |
| Veuillez répondre à "JMeter Users List" <jm...@jakarta.apache.org> |
| |
| |
| |
| |
| |
| |
| |
| |
| Pour |
| |
| jmeter-user |
| |
| Objet |
| |
| Distributed Testing and Properties |
| |
| |
| |
| |
| |
| |
| |
>------------------------------------------------------------------------------------------------------------------------------------------------|
I've inherited some jmeter performance tests, and I have hit a snag
running one of them in distributed mode. The test in question works
fine in non-distributed mode. It uses properties in an external file
to drive dynamic portions of the test (number of threads/loops,
appserver name, appserver port, etc.). These properties are added to
the jmeter runtime environment by using the -p option to jmeter:
jmeter -t target_test.jmx -p devtest_100x5.properties
The test then uses ${__property(prop.name)} to pull values from
'devtest_100x5.properties' into the test. This is a very nice
technique since I can leave the jmx test definitions untouched while
enabling different levels of stress testing against differing
environments just by choosing among a handful of canned property
files. (For me it is easier and less error-prone to edit a property
file than to open the jmeter gui and click a bunch of widgets.)
Now for my question: When I attempt to run this test in a distributed
mode, none of the properties in 'devtest_100x5.properties' are
available to the slave jmeter-server instances. I had hoped that
either (1) all known properties on the jmeter master got pushed down
to the slave (it appears the jmx files are pushed this way) or (2) the
jmeter master would perform the property substitution before pushing
the jmx file to the slaves. For the record, a hardcoded version of
the test (without the property substitution) worked fine in
distributed mode.
Am I heading down a dead-end road here? It's starting to look like
the property file usage of the original test breaks some fundamental
assumptions of jmeter. Will I be stuck writing N statically-defined
jmx files to cover the cross-product of thread/loop/server/port/etc
possibilities?
Thanks for reading, and I hope somebody can come up with an answer.
Cheers,
AK
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org