I have a jmeter test plan that is running in a non gui mode on linux to test a server. I want to pause the jmeter test plan for some time to carry some maintenance on server and want to resume the test plan from where it got paused.
I don't know when to stop the test plan before hand, so i can't use timers to code in jmeter
Is there a pause button on jmeter GUI and NON GUI mode to pause the test plan
Linux solution. If you're running Linux you can use kill command like:
kill -STOP 1234 - pause JMeter
kill - CONT 1234 - resume JMeter
replace 1234 with the associated Java process ID
JMeter solution. You can add Constant Throughput Timer to your test plan and set the desired throughput in "requests per minute" using __P() function. When you need to suspend JMeter - you can set the desired throughput to 0 via Beanshell Server. Check out How to Change JMeter´s Load During Runtime article for comprehensive information if needed.
It is not possible to pause Jmeter execution.Thread groups are configured in such a way that it wind through requests and execute test plans fully. The only way to make changes in server is to stop the test, change what you need to and then execute the test again from the beginning.
Also, the test will not make any sense when you resume it after updates in server. Because mostly when updates are done on servers, apache will be restarted for safer side. That means the requests you sent previously is not anymore in the queue. So, even if there is a pause button in JMETER, the test after resume would be the same as that of a new test.
Best practice to do: Run test completely before server update. Take out the results.
Run test after server update. Take out the results.
Then compare the results.
Related
I am posting data to a REST API using HTTP POST requests. The jmeter setup is single thread. As i am making 200,000 post calls i want to pause the run when needed and i want to resume the run when needed.
NOTE: i am running the jmeter in NON GUI mode on Linux server, which will not have a GUI for anything.
Other important thing is i can't program it before the run starts because i'm not sure when to pause the suit or when to resume it.
JMeter-specific solution would be using Beanshell Server and Constant Throughput Timer combination.
Add Constant Throughput Timer to your test plan and set your desired throughput in requests per minute. If you don't want to limit JMeter - set it to something very high using __P() function
${__P(throughput,10000000)}
Enable Beanshell Server by adding the next 2 lines to user.properties file:
beanshell.server.port=9000
beanshell.server.file=../extras/startup.bsh
Create 2 scripts like
suspend.bsh containing the next line:
setprop(throughput, 0);
and resume.bsh containing the next line:
setprop(throughput, 10000000);
Whenever you need to suspend your test invoke the following command from "lib" folder of your JMeter installation:
java -jar bshclient.jar localhost 9000 /path/to/your/suspend.bsh
Chwck out How to Change JMeter´s Load During Runtime article for more details.
Linux specific solution would be using kill command like:
to suspend: kill -SIGSTOP JMETER_JAVA_PID
to continue: kill -SIGCONT JMETER_JAVA_PID
where JMETER_JAVA_PID is process id of the JVM which is running JMeter, you can find this out using jps command
I have a simple twisted application which I run using a systemd service, executing a script, which subsequently executes a .tac file.
The application is structured as a JSON RPC endpoint (fastjsonrpc), built into a t.w.r.Resource, which is in a t.w.s.Site, and served t.a.i.TCPServer, and the whole thing packed into a t.a.Application. This works fine.
Where I do run into trouble is when I try to warm up caches at startup. This warm-up process is pretty slow (~300 seconds), and makes systemd timeout and kill the process. Increasing the timeout is not really a viable option, since I wouldn't want this to block system boot.
Analogous code is used in a separate stack running on Flask from within Apache and wsgi. That server starts itself off and lets systemd go on while it takes its time building the caches. This behaviour is fine for me.
I've tried calling the warmup function using the following within the setup function of the t.w.r.Resource:
reactor.callLater(1, ep.warmup, None)
I've not yet tried using this from within systemd, and have been testing it from twistd directly on the command line. The server does work as expected, however it no longer responds to SIGINT (^C). Removing the callLater is all that's needed to let the server respond to SIGINT.
If the warmup function is called directly (not by callLater, i.e., the arrangement which makes systemd give up while waiting for warm up to complete), the resulting server also continues to respond to SIGINT.
Is there a better / good way to handle this sort of long-running warmup code?
Why would twistd / the reactor not respond to SIGINT? Am I missing something here?
Twisted is a single-threaded thing. It sounds like your "cache warmup" code is blocking the reactor for those 300 seconds. One easy way to fix this would be using deferToThread to let it run without blocking the reactor.
I'm using a open-source chef server managing about 150 nodes.
Analytics/Reporting module is not activated in the chef server due to resource constraints.
"chef-client" is running on all the nodes every 30 minutes
How can I find, how much time each chef-client run is taking to complete?
I'm trying to find the nodes that are slowest in completing their chef-client runs
Chef Server doesn't store this information. You'll need to manage it yourself, possibly using a handler as linked above in the comments. A simple option would be to make a handler which stores the duration of the last run as a node attribute, but the sky is the limit. If you want something to help debug long runs once you find them, check out my poise-profiler cookbook.
I am running 340 concurrent users to load test on server using jmeter.
But on most of the cases jmeter hangs up and won' t return, even if I try to close the connection it just hangs up. and eventually I have to close the application.
Any idea how to check what is holding the requests and how to check the requests sent by jmeter and find the bottleneck.
Got the following message on closing the thread
Shutting down thread please be patient message
I've hit this several times over the past few years. In each of my cases (may not be in your's) the issue was with the Load Balance (F5) I was sending my traffic through. Basically a property called OneConnect was holding the connections in a time-wait state and never killing the connection.
Run a pack tool like wireshark and see what's happening with the requests.
Try distributed testing, 340 concurrent users is not a big deal, but still you can try if that decreases your pain. Also take a look at the following link:
http://jmeter.apache.org/usermanual/best-practices.html#lean_mean
First check you script is ok with one user.
Ensure you use assertions.
Then run you test following jmeter best practices:
no gui
no costly listeners
You should then be able to see in csv output the longest request and be able to fix your issue.
I also encountered this problem before when I run my JMeter on my laptop(Core 2 Duo 1.5Ghz) it always hang-up in the middle of the processing. I tried to run on another pc which is more powerful than my laptop and its works now smoothly. Therefore, JMeter will run effectively if your pc or laptop has a better specs.
Note: It is also advisable to run your JMeter in non-gui mode.
Example to run JMeter in Linux box:
$ ./jmeter -t test.jmx -n -l /Users/home/test.jtl
I had the
one or more test threads won't exit
because of a firewall blocking some requests. So I had to leap in the firewalls timeout for all blocked request... then it returned.
You are getting this error probably because JVM is not capable of running so many threads. If you take a look at your terminal, you will see the exception you get:
Uncaught Exception java.lang.OutOfMemoryError: unable to create new native thread. See log file for details.
You can solve this by doing Remote Testing and have multiple clusters running, instead of one.
Any ideas as to why my Apache/2.0.49 server always waits 20 seconds from receiving a request that is executed using a cgi-bin script to starting to run that script?
The server responds immediately to normal HTTP requests that only use static files, but always takes 20 seconds to respond to cgi-bin requests. I've used tcpdump to time the arrival of the request and printed the time at the beginning of the script to determine that the delay is between those two events.
I can't see anything in the configuration that relates to 20 seconds. The server runs Red Hat Linux 3.3.3-7 & I'm pretty sure that it used to respond to cgi-scripts immediately, but am unsure when it started being slow & what might have changed to cause that.
Thanks in advance for any help/suggestions you may be able to provide.
We had a similar problem with our Apache server running PHP but only with a specific client, in the end it turned out the issue was that the PHP was trying to fetch a file from a remote server but didn’t have connectivity, after 20 seconds the PHP “gave up” and the flow was completed. You should try to search your code for something similar.