I am using jmeter, I have one perl script which I am calling from testcase (I am using autoshell property of jmeter and to execute the script) and which will execute at server side ( remote machine) not at jmeter machine, Problem is once that script is being executed at remote machine, I should able to catch the response i.e. return 1 or return 0 whatever it is.. Since the script is running at server its hard to catch the return 0 or return 1 in jmeter and based on this return values I have to decide whether my test case is pass or fail. I thought to use OS sampler I don't know how useful it will be in this case and for response I thought I will use response assertion but being new to jmeter its hard for me to find out the solution. Can I get some initial level of help, How can I do it.. If anything is not clear please let me know..
You can use OS Sampler, it has a Return code configuration in it. You can select "check return code" and set the expected return code. The JMeter thread waits until a return code is received. You can also use Response Assertion to check the script output. Only downside with using OS Sampler is you need to start JMeter server agent at the remote machine and then only can run it.
You can also try SSH Command. It helps in executing commands in linux box and don't need a server start as well.
Related
I am using jmeter to test at my dev server.
The Scenario is like This.
0. Turn OFF all firewalls both local PC(so called, HOST) and client PC(so called, CLIENT)
Turn on Jmeter at my HOST
--> add Thread Group, bzm-Parellel Controller. I am not certain at this point
Connect to CLIENT (once)
-> maybe, by SSH Command or REMOTE Start
execute my test script at CLIENT (several times, more than 100 times)
-> such as, 'ls' 'pwd' 'mkdir dir123' 'ls' IN A ROW!!
-> maybe, by OS Process Sampler. I am not certain at this point
get result of (3) at my HOST jmeter by View Results Tree
This is the scenario that I Thought
Can anyone help me with this issue.
Cuz, there's too many Samplers and less information, I'm suffering such a tough moments.
Thank you for reading.
Turning off firewall is not the best idea, just open the port you will be using, default port for SSH is 22 and normally it's getting opened more or less automatically when you install OpenSSH server
I don't think you need Parallel Controller, it has very specific use cases like simulating AJAX requests, it will be sufficient to specify the desired number of users/loops/test duration on Thread Group level
Remote start is for JMeter distributed testing, if you want to run a shell command on the client use OS Process Sampler or SSH Command sampler, see How to Run External Commands and Programs Locally and Remotely from JMeter article for more details.
The same is for point 2, if you need to create a directory depending on your HOST and CLIENT operating systems you need to choose one of the aforementioned samplers. Just be aware that only first operation/iteration succeeds, all the subsequent attempts you will get cannot create directory ‘dir123’: File exists. I'm also not certain what you're trying to test here? SSH server performance? Operating system performance? Network performance?
If you add View Results Tree listener to your Test Plan and run your test in GUI mode it will automatically catch all the Samplers results
I'm running tests with JMeter (master+10 slaves) on elasticasearch. I'm getting error 400 for some requests but they are a bit elusive:
When I run the requests manually with curl or pasting them on kibana's console, I don't get errors.
Every time I run the tests using jmeter, using the same requests and under the same conditions, I get a different number of errors.
So I was thinking of inspecting the response bodies from jmeter. But all the ways I've tried failed:
I've created a View Result Tree element and checked all boxes on the "configure" panel. When I run the script, it logs everything except response data
I've tried a BeanShell post processor to write all responses on a file. But it apparently is being 'ignored' when I run the script
Both these solutions work on my machine, but not on the server (which I don't have total control over). I'm passing jmeter.save.saveservice.response_data=true on the command line to start jmeter.
What else could I try?
This is an optimization that JMeter makes for distributed testing related to the mode:
https://jmeter.apache.org/usermanual/properties_reference.html#remote_batching_config
To avoid JMeter stripping the response data set in user.properties of servers snd controller:
mode=Batch
As by default it is:
mode=StrippedBatch
By default JMeter slaves don't send response data to the master, you can choose a different sample sender if you need more data.
Writing response data into a file using Beanshell should work in any case (however consider using JSR223 Test Elements and Groovy for this), just make sure that:
your Beanshell PostProcessor is placed correctly according to JMeter Scoping Rules
there are no Beanshell-related messages in jmeter.log files
you will need to collect the log files from each slave manually after test run, they will not be generated on the master
I created JMeter Test and under first "HTTP Request" I created a Beanshell listner script which works fine when using GUI but 8 out of 10 times the script totally get ignored in non-GUI mode.
I am also running these test in Gitlab CI using Docker Image "justb4/jmeter:latest" and Beanshell script also get ignored there. I don't know whats wrong there it is working fine with GUI
There is no such thing as "get ignored" in JMeter world, it either passes or fails, in case of failure you should see the relevant message(s) in the jmeter.log file
Also be aware that you should not be using Beanshell at all, starting from JMeter 3.1 you should be using JSR223 Listener and Groovy language for scripting, one of Beanshell's disadvantages is that it's being interpreted each time while Groovy scripts can be compiled and cached providing the most optimal performance. See Apache Groovy - Why and How You Should Use It article for more details.
Also be informed that we cannot efficiently help without seeing your code and the aforementioned jmeter.log file.
I am running a jmeter test, POST submitting a request i need to check the application log(openshift) to find an application specific message/id is generated ,it need to be captured as its a test data for my subsequent request. Any solution is much appreciated.
Depending on your setup you can go for:
Normal HTTP Request call to /api/v1/namespaces/$NAMESPACE/pods/$NAME/log
Run oc log command using OS Process Sampler or SSH Command sampler
WHAT I HAVE:
Jmeter network created for tests in distributed mode: one Jmeter master plus few Jmeter slaves. BeanShell Server disabled. Everything works fine.
WHAT I WANT TO DO:
I want to enable BeanShell server to be able to modify properties on the fly.
ACTUAL RESULT:
BeanShell server starts and works successfully.
Once the test is done, the following message appears in the log:
The JVM should have exited but did not.
The following non-daemon threads are still running (DestroyJavaVM is OK):
Thread[Thread-7,5,main], stackTrace:java.net.PlainSocketImpl#socketAccept
java.net.AbstractPlainSocketImpl#accept at line:409
java.net.ServerSocket#implAccept at line:545
java.net.ServerSocket#accept at line:513
bsh.util.Sessiond#run at line:65
java.lang.Thread#run at line:748
Thread[Thread-5,5,main], stackTrace:java.net.PlainSocketImpl#socketAccept
java.net.AbstractPlainSocketImpl#accept at line:409
java.net.ServerSocket#implAccept at line:545
java.net.ServerSocket#accept at line:513
bsh.util.Httpd#run at line:64
java.lang.Thread#run at line:748
It's clear that it happens because of BeanShell server that is running and doesn't exit for some reason.
As a result, java process will never exit and will hang.
QUESTION:
Any ideas why it happens? How to avoid it? I don't connect to beanshell server, neither by http nor by telnet.
MORE DETAILS:
All the nodes are running as Docker containers.
All nodes are deployed in AWS.
Can't reproduce the same issue locally on my machine. Even with BeanShell server enabled, all works smooth, and java exists as it should.
WHAT I TRIED:
Tried to set up the following properties:
jmeterengine.remote.system.exit=true
jmeterengine.stopfail.system.exit=true
jmeterengine.force.system.exit=true
Doesn't help, java process still hangs.
The same for
bsh.system.shutdownOnExit = true;
Any ideas are very much appreciated.
I don't think there is a way of stopping the Beanshell Server along with the test as it runs in an endless-loop Thread
I would recommend stopping your test and the Beanshell server using a .bsh file like:
stopEngine();
Thread.sleep(5000L); // just in case wait for 5 seconds for graceful shutdown
System.exit(0);
where:
stopEngine() is a shorthand for StandardJMeterEngine.stopEngine(), it's defined in startup.bsh
System.exit(0); - basically shuts down the whole JVM with 0 exit status code
So you will be able to turn everything off the same way you amend the properties in the runtime.
You can also achieve the same by executing the System.exit(0); command automatically from i.e. tearDown Thread Group using OS Process Sampler, however in this case make sure to set the following property:
jmeter.save.saveservice.autoflush=true
otherwise you can loose some results which have not been written to disk yet
Finally, I found a workaround, so posting it as an answer here.
Actually, it doesn't answer the original question in fact, but don't want to waste time trying to find an original root cause as it seems to be related to AWS structure (just because I can't reproduce it locally inside the same container I launch remotely).
So, the final schema is:
To update properties on the fly, I don't have to launch BeanShell on slave and master both. Real property change happens on slave, so master is not required. It solves my specific case.
To stop test, you can use existent shutdown.sh and stoptest.sh scripts. No need to do it over beanshell server.
If the test was properly stopped, then -X option (server.exitaftertest=true) also works fine, so force shutdown for JVM is not required, and you don't have to add tearDown thread group that does System.exit. But the idea is nice.
It's worth to have a shutdown.bsh script to force kill it anyway as a tool.