I am using a Thread Group with Number Of Threads = 5 with an HTTP request.
In the request I want to include a parameter with the value of the thread number, e.g.,
"pageno": ${threadno}
I want to get the thread number like ${threadno}.
How can I do that?
The thread number is available as:
${__threadNum}
See: functions reference
While the above-mentioned ${__threadNum} will work in many places within jMeter, you'll need to use something else where it is not allowed, e.g., script elements within Pre/Post-Processors.
This answer explains how to get thread number or count within such a script in jMeter.
To get the number of the current thread (out of 5 in your case) use ctx.getThreadNum() which will get the number of the thread.
To get the total number of threads being used by jMeter you can use ctx.getThreadGroup().getNumThreads() or ctx.getThreadGroup().getNumberOfThreads() for total active threads.
https://jmeter.apache.org/api/org/apache/jmeter/threads/JMeterContext.html#getThreadNum()
https://jmeter.apache.org/api/org/apache/jmeter/threads/AbstractThreadGroup.html
For those looking for the number of active threads in the entire test plan, not just a particular ThreadGroup.
${__groovy(org.apache.jmeter.threads.JMeterContextService.getNumberOfThreads())}
${__threadNum} does not work well alone.
You will need use ${__eval(${__threadNum})}.
Try to use this:
int threadNum=ctx.getThreadGroup().getNumThreads();
ctx is from JmeterContext
Related
I am trying to build a test plan in JMeter based on a specific thread time series.
For example, I know that at time x, there are n(x) users, and at time x+t, there are n(x+t) users, and so on. The issue is that the number of users has to be updated for t ~= 500ms, and the thread number is in a range of 20 - 200.
Also, ideally, I would like to add and remove threads for the next time slot from the active threads instead of building new threads every time to save resources.
I was trying different tricks to simulate this scenario:
Using execution of Thread Groups sequentially, you can set the duration lifetime but in seconds, every thread will be killed after the specific time slot and recreated in the following thread group.
Using the ultimate thread group, you can define your series of threads for each time interval but still in seconds, and it goes to generate new threads for each timeslot.
In both cases, if you fill the duration box with a value of 0.5, it seems not to recognize it or not work fine.
Do you have any suggestions on how to implement this scenario?
I'm not aware of any Thread Group which has milliseconds precision, but you can try to extrapolate it, for example if you need to add 100 users in 500 ms you can try kicking off 200 users in 1 second and it should be more or less desired load pattern.
The only implementation of thread pool pattern I'm aware of is Throughput Shaping Timer in combination with the Concurrency Thread Group via Feedback Function
And last but not the least there is a possibility to start new threads and stop running ones from JSR223 Test Elements like:
ctx.getThreadGroup().addNewThread(0, ctx.getEngine()) // starts new thread and returns its instance
ctx.getThreadGroup().stopThread('name of the thread', false) // stops the given thread, 2nd argument is for force stop
I have a shell script that copies files into a location and another one that picks these up for further processing. I want to use multithreading to pick up files parallelly in Scala using a threadpool.
However, if there are two threads and two files, both of them are picking up the same file. I have tried the program a lot of times, and it always ends up like this. I need the threads to pick up different files in parallel.
Can someone help me out? What approaches can I use? If you could point me in the right direction that would be enough.
I think you can use a parallel sequence to do the processing in parallel.
You don't have to handle this logic yourself. for ex. the code could be like this:
newFiles:Seq[String] = listCurrentFilesNames()
newFiles.par.foreach { fileName =>
processFile(fileName)
}
This code will be executed in parallel. and you could set the number of threads to a specific number as mentioned here: https://stackoverflow.com/a/37725987/2201566
You can also try using actors - for eg- for your reference - https://github.com/tsheppard01/akka-parallel-read-csv-file
Scenario is we are generating token during execution which would further be used in other threadgroup.
Like:
In first thread group, tokens will be generated for 100 users.
In second thread group, 50 users will utilize the tokens.
In third thread group, next 50 users will utilize the tokens.
Query is:
1. How do we save tokens that is generated during run time?
2. How to use first 50 tokens on second thread group and rest other 50 on third thread group?
If you need to use a Token generated by a request in following requests then use 1 Thread Group and not many.
Threads in different ThreadGroup have absolutely no relation and are considered as different users, so although you may use elements like InterThreadCommunication to do that, just DON'T.
If you use same thread group then it's just a matter of using the correct extractor to generate variables and then use them using ${varName}.
You can transfer a value between Thread Groups by converting it into a JMeter Property. According to the documentation:
Properties are not the same as variables. Variables are local to a thread; properties are common to all threads, and need to be referenced using the __P or __property function.
So if you need to transfer something from one thread group into another:
Convert the value into a JMeter Property using __setProperty() function like:
${__setProperty(foo,bar,)}
Once done the value can be accessed usine __P() function like
${__P(foo,)}
Demo:
If the value is different for different threads - you can combine the above approach with __threadNum() or __counter() functions in order to use current virtual user number or next incremented number as a prefix or a postfix for the function.
I need to simulate "real traffic" on Web farm, by other words I need to generate high peaks but as well periods which less or even no HTTP requests (hits) at all. Reason for that is to test some atomized mechanisms for adding and reducing CPU and memory for Web servers itself (that is another story). That is why I need "totally random" sceneries when I have loads but as well period with zero or less traffic (so I can add or reduce compute power).
This is situation that I get now, as you can see I always have some avg load its always around some number of hits, even if I change 10 to 100 threads. Values (results) will always have some average value. There are no periods with less or more traffic which would be separated be +10 mints or so, only by few seconds.
Current situation
I would like to get "higher" variations by HITS/REQUESTS with some time breaks between it.
Situation that I want: i.stack.imgur.com/I4LhU.png
I tried several timers but no success and I do not want to use "Ultimate Thread Group" and similar components because I want test to be totaly randome and not predefined with time breaks and pause periods (thread delays). I would like test which will be totally randomized by it self - which could for example generate from 1 to 100 users per XY time.
This is my current Jmeter setup: i.stack.imgur.com/I4LhU.png
I do not know if I am missing some parameter in current setup or there is totally another way to do this.
Thanks a lot!
If this is something you really want (I strongly believe that the test needs to be repeatable, not random), I would suggest using Constant Throughput Timer for this. Despite the word "Constant" in its name you can use a Function or a Variable there, for instance __Random() and you will get different controllable "spikes" each iteration.
Moreover, you put a __P() function and amend its value via Beanshell Server while the test is running
I want to write a SystemTap script that can determine the actual number of threads for the current PID inside a probe call. The number should be the same as shown in the output of /proc/4711/status in this moment.
My first approach was to count kprocess.create and kprocess.exit event occurrences, but this obviously gives you only the relative increase / decrease of the thread count.
How could a SystemTap script use one of the given API functions to determine this number ? Maybe the script could somehow read the same kernel information as being used for the proc file system output ?
You will be subject to race conditions in either case - a stap probe cannot take locks on kernel structures, which would be required to guarantee that the task list does not change while it's being counted. This is especially true for general systemtap probe context, like in the middle of a kprobe.
For the first approach, you could add a "probe begin {}"-time iteration of the task list to prime the initial thread counts from a bit of embedded-C code. One challenge would be to set systemtap script globals from the embedded-C code (there's no documented API for that), but if you look at what the translator generates (stap -p3), it should be doable.
The second approach would be to do the same iteration, but for locking reasons above, this is not generally safe.