I need to run a distributed test with some of the command line parameter and also I need to pass My server IP with -Djava.rmi.server.hostname=IP, since I am running it from the command line I need nee to give as
jmeter -n -t C:\\Jmxfile.jmx -r Gsomeproperty=value in command line.
I am confused of passing even the command line parameter and also hostname? can somebody help me in sending both at a time.
Check the documentation:
Java system properties and JMeter properties can be overridden directly on the command line (instead of modifying jmeter.properties). To do so, use the following options:
-D[prop_name]=[value]
defines a java system property value.
-J[prop_name]=[value]
defines a local JMeter property.
-G[prop_name]=[value]
defines a JMeter property to be sent to all remote servers.
-G[propertyfile]
defines a file containing JMeter properties to be sent to all remote servers.
So, you can send both at a time through the command line.
Related
So I got this error when added additional parameters. Now I've got 14 parameters, when I had 11 it worked fine. Is there any way to increase number of parameters powershell can send to jmeter ?
The number of arguments doesn't really matter, you might be suffering from CreateProcess API function parameter length limit which is 32767 characters.
Also it might be the case there is a problem with your filesystem, follow How To Fix File System Error -1073741819 in Windows 10 article for troubleshooting steps.
Also be aware that if you're passing multiple JMeter Properties via -J command-line arguments you can avoid this by putting the properties values into user.properties file or create your own .properties file and pass it to JMeter via -q command-line argument.
References:
Full list of command-line options
Apache JMeter Properties Customization Guide
Overriding Properties Via The Command Line
I have some scripts that I run using jboss-cli -c --controller=... --file=myscript.cli.
The -c and --controller options are great, because my script does not know which server it should be run against and can be reused for multiple servers.
I now want to use the offline-cli feature to avoid port conflicts and prevent servers from beeing reachable through the network while they are beeing set up.
My issue is now that in order to start an embedded server I have to use the CLI-command embed-server, but I don't want to add that command to my scripts, because the scripts are not supposed to know the name of the server config xml file.
Unfortunately I can't use both --command="embed-server --server-config=my-standalone.xml" and --file=myscript.cli at the same time, because the CLI complains with:
Only one of '--file', '--commands' or '--command' can appear as the argument at a time.
Another thing I tried was: --commands="embed-server --server-config=my-standalone.xml,run-batch --file=\"myscript.cli\" but this does not work either, because my scripts contain some if-else logic, for instance:
if (outcome == success) of /subsystem=iiop-openjdk:read-resource()
/subsystem=iiop-openjdk:remove()
end-if
And unfortunately conditional logic is not supported in batch mode (see https://bugzilla.redhat.com/show_bug.cgi?id=1083176).
the simple way is to start your embedded server in your script :
embed-server --std-out=echo --server-config=standalone-full.xml
/subsystem=messaging-activemq/server=default/jms-queue=inQueue:add(durable=true, entries=["/queue/inQueue","java:jboss/exported/queue/inQueue"])
/subsystem=messaging-activemq/server=default/jms-queue=outQueue:add(durable=true, entries=["/queue/outQueue","java:jboss/exported/queue/outQueue"])
quit
Don't forget to quit at the end of your cli script :)
If you are using a Unix system you may try something like this:
(echo embed-server --std-out=echo --server-config=my-standalone.xml; cat myscript.cli) | jboss-cli.sh
Is it possible to run perl script, which is located on a remote server, on that server from Windows? There is a job on a remote server that I want to get done every time I make something on Windows.
You have to have something listening for an instruction to run the script, and then you have to send the instruction.
There are lots of approaches you could take to that, including:
Running an SSH server and then connecting to it from an ssh client on the windows machine
Running an HTTP server, running the script through FastCGI, and then requesting the URL for it from curl or a browser on the Windows machine
Writing a custom protocol, listening on a socket, and then writing a custom client that you run on the Windows machine
Absolutely.
You can use plink to run commands on the server from Windows, assuming the server is running sshd.
plink user#a.domain.ext echo hi
This will print "hi\n" to the standard output.
Substitute /path/to/perl/script for echo above and substitute hi with any command line argument that the script needs.
plink is available here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
One cautionary personal note from doing this many times is that the environment in which the perl script will be run is much less complete than what you would experience when logging in via a full SSH session and running the command interactively. Many environment variables you would normally expect are unset.
For instance using "set | wc -l" in the command above produces only 39 environment variables defined, but from an interactive SSH session, there are 57 environment variables defined. You have to make sure your perl script isn't depending on an environment variable that hasn't been set. For instance, you may need to use full paths for any modules that it uses, or by using the -I flag in the shebang line, because #INC may not be what you expect it to be.
when I doing a calculation halfway, I just found the runtime limit 50:00 may not be sufficient. So I use $bstop 1234 to stop the job 1234 and try to modify the old runtime -W 50:00 to -W 100:00
Can you suggest a command to do so?
I tried
$ bmod -W 100:00 1234
Please request for a minimum of 32 cores!
For more information, please contact XXX#XXX.
Request aborted by esub. Job not modified.
$ bmod [-W 100:00| -Wn ] 1234
-bash: -Wn]: command not found
100:00[8217]: Illegal job ID.
. Job not modified.
according to
[-W [hour:]minute[/host_name | /host_model] | -Wn]
from http://www.cisl.ucar.edu/docs/LSF/7.0.3/command_reference/bmod.cmdref.html
I don't quite understand the syntax, -Wn does it mean Wall time new
Many thanks for your help!
The first command fails because LSF calls a the mandatory esub defined by your administrator to do some preprocessing on the command line, and this is returning an error. Here's the relevant quote from the page you linked:
Like bsub, bmod calls the master esub (mesub), which invokes any
mandatory esub executables configured by an LSF administrator, and any
executable named esub (without .application) if it exists in
LSF_SERVERDIR.
You're going to have to come up with a bmod command line that passes the esub checks, but that might cause other problems because some parameters (like -n I believe) can't be changed at runtime by default so bmod will reject the request if you specify it.
The -Wn option is used to remove the run limit from the job entirely rather than change it to a different value.
Is it possible to have a Perl script run shell aliases? I am running into a situation where we've got a Perl module I don't have access to modify and one of the things it does is logs into multiple servers via SSH to run some commands remotely. Sadly some of the systems (which I also don't have access to modify) have a buggy SSH server that will disconnect as soon as my system tries to send an SSH public key. I have the SSH agent running because I need it to connect to some other servers.
My initial solution was to set up an alias to set ssh to ssh -o PubkeyAuthentication=no, but Perl runs the ssh binary it finds in the PATH instead of trying to use the alias.
It looks like the only solutions are disable the SSH agent while I am connecting to the problem servers or override the Perl module that does the actual connection.
Perhaps you could put a command called ssh in PATH ahead of the ssh which runs ssh as you want it to be run.
Alter the PATH before you run the perl script, or use this in your .ssh/config
Host *
PubkeyAuthentication no
Why don't you skip the alias and just create a shell script called ssh in a directory somewhere, then change the path to put that directory before the one containing the real ssh?
I had to do this recently with iostat because the new version output a different format that a third-party product couldn't handle (it scanned the output to generate a report).
I just created an iostat shell script which called the real iostat (with hardcoded path, but you could be more sophisticated), passing the output through an awk script to massage it into the original format. Then, I changed the path for the third-party program and it started working fine.
You could declare a function in .bashrc (or .profile or whatever) with that name. It could look like this (might break):
function ssh {
/usr/bin/ssh -o PubkeyAuthentication=no "$#"
}
But using a config file might be the best solution in your case.