is it possible to open multiple lanes within playbook in parallel
for example lets assume i have
Right now we have all the questions stored in a table which has all the questions
Lane1
question-1
question-2
question-3
question-4
Lane 2
question-1
question-2
question-3
question-4
Lane 3
question-1
question-2
question-3
question-4
now if i want to open up all the lanes in parallel so that multiple agents can update without performance impact
Related
Azure Function architecture:
So we are setting a pipeline in Azure Datafactory, it contains 4 triggers to trigging Function1 at the same time with 4 different parameters.
Pipeline -> Function1-param1 Function1-param2 Function1-param3 Function1-param4
Yesterday, I tried to trigger that pipeline 2 times in 5 minutes, e.g. 10:30 and 10:31. That means, that time I tiggered Function1 for 8 times in 5 minutes.
Pipeline ->
time 1 Function1-param1 Function1-param2 Function1-param3 Function1-param4 10:30
time 2 Function1-param1 Function1-param2 Function1-param3 Function1-param4 10:31
Strange thing is that, we expect 8 calls running parallel cause FUNCTION_WORKER_PROCESS_COUNT is setting to 10, but there are only 6 calls running parallel, 2 are running after that.
So the question is, what is the relationship between FUNCTION_WORKER_PROCESS_COUNT and the tasks that can running parallel.
Function is written in Powershell 7.
AFAIK, the maximum number of worker processes per Function host instance is limited by the FUNCTIONS WORKER PROCESS COUNT variable. These instances are treated as independent VMs, with the FUNCTIONS WORKER PROCESS COUNT limit applied to each one.
If the FUNCTIONS WORKER PROCESS COUNT is set to 10, each host instance will perform 10 individual functions at the same time.
Multiple Workers means Multiple Process Ids of the Same Function App which is a logical collection of Functions.
One Worker Process can host all functions of one Function App where the Single Host has the default value as 1 to the FUNCTIONS_WORKER_PROCESS_COUNT and the Function Host means it is the Physical/Virtual Host where Function App runs as Windows/Linux Process.
Refer here for more information on mechanism of FUNCTIONS_WORKER_PROCESS_COUNT.
Scaling out also allows you to adapt to changes in demand more quickly.
To meet resource requirements, services may usually be swiftly added or removed. This flexibility and quickness efficiently saves spending by only using (and paying for) the resources required at the moment.
Refer this article for more information on the benefits of Scale Up and Scale out.
References of more information on FUNCTIONS_WORKER_PROCESS_COUNT:
Azure Functions - Functions App Settings - functions_worker_process_count
Azure Functions - Best Practices - FUNCTIONS_WORKER_PROCESS_COUNT
I have created seven thread groups which execute different scenarios in one application. I'm trying to optimize my scripts in order to be more maintainable and easy to master when someone else uses them.
The thing that i cannot figure out is how can i combine those thread groups into one or two and to still have the seven different execution paths and the possibility to control them, by control i mean to set how many users to execute scenario 1, how many to execute scenario 2 etc. till 7.
Currently the test plan looks like this
If you don't want several thread groups for some reason the alternative options are in:
Throughput Controller - with different global executions or execution percentages
Switch Controller - which provides random weighted values (in some cases Throughput Controller doesn't guarantee that samplers in scope will ever be executed)
See Running JMeter Samplers with Defined Percentage Probability guide for more information on configuration and implementation.
Well i just figured out how to do that i have added a Loop controller a Random Order Controller as child of the loop controller. And i have put seven throughput controllers as child of the Random Order Controller so now everything looks fine
I was using non-GUI mode to perform a remote load testing with Jmeter from master server (Linux) to 5 slave servers (Linux). 5x "n" users have been run, "n" users on each server.
The results have been written to master server.
There are samples from all servers in results file but they relate to the number of active users from particular servers ("n") and not from all servers (5x "n").
There are no information in the result file about the real number of active users on all the servers.
As a result, a maximum number of active users is "n" on generated graphs which does not reflect the real load (5x "n" users).
Has anyone got a similar problem?
Is there anything I can do to correct the results already gathered?
Should I change any JMeter parameter to get the correct results in the next run?
Short Answer:
This is normal and no, there's nothing in JMeter you can do to fix it.
Long Answer:
Each Load Generator creates a number of threads n: the threads will be numbered 1-n. When the Controller collects all of the information, it sees 5 results for Thread 1, 5 results for Thread 2, ... Thread n. The Controller has no way of knowing that each of them are 5 separate concurrent threads and not just the same thread 5 sequential times.
Fixing it:
It depends on what you mean by a maximum number of active users is "n" on generated graphs. If this is something inside JMeter, then no, you can't fix it.
If it's a report-generator that you have created yourself, then yes, you can fix it by passing in the number of load generators.
I'm running a distributed test using 5 JMeter clients (slaves). Each client is set to run 50 users. At the conclusion of the test I generate a series of graphs from the resulting JTL along with a SynthesisReport. The SynthesisReport details 250 samples for each request, as you'd expect, however the TimeVsThreads and the ThreadsStateOverTime peak at 50 users, as if they were showing the results from just one of the clients.
I've confirmed that the jmeter.properties files for each client are the same as I suspected that it was possibly an issue with the each clients results file configuration and settings for saveservice.
I can't imagine this is by design, has anyone experienced something similar and if so how did was it solved?
As per documentation:
http://jmeter-plugins.org/wiki/ActiveThreadsOverTime/
Just name your thread groups using a unique id for each generator ( hostname or a property you pass to injector and use with function __P if you have more than 1 injector per host) and it will work fine.
This is normal for Jmeter Distributed Testing.
The reason this occurs is that each load generator separately starts User Threads 1-50, so when cmdrunner runs, it sees 1 responses from each User Thread 1 (5 total), but can't differentiate between them.
If you're using a custom reporter tool (that wraps cmdrunner), you can multiply your peak users by your load generators to display a more accurate number at the top of your Report. But as long as you're calling cmdrunner, you won't be able to see the actual number of users on your graphs.
This is normal behavior of JMeter. 5 clients will run each 50 threads.
Open JMeter and run on all remote hosts, and check Active threads each will run 50 threads.
The default behavior of JMeter definitely seems to just duplicate your test plan across servers. So, if the test plan has 10 "threads", running it against X servers will yield 10x threads.
Is there any way to make this more intelligent? For example, maybe I only want one copy of some HTTP thread running even though I have 5 servers to distribute a more intense load.
Another example...I want to ensure that my sampler uses unique IDs for each thread, but my service requires that the usernames be pre-provisioned so they can't be preprovisioned...I haven't been able to find a straightforward way to coordinate this (statelessly) across my distributed servers.
A "simple" implementation might be if JMeter had distributed testing aware variables built in so the client sent the server something like ServerID and ServerCount so that the test plan could use the numeric serverId as a prefix or mod by the server count. Alternatively, JMeter could have an option to shard thread_num so that if you say 10,000 threads and have 10 servers, it will run 1,000 threads on each server with thread_num never being duplicated across the distributed test for a given sampler (Example, skip thread_num if thread_num % serverCount != serverId).
Any thoughts on the best way to accomplish this?
One approach to have distributed test-aware variable is to start each jmeter-server with different variable value:
bin/jmeter-server -Jvariable=valuehost1
And then in your test script just use:
${__P(variable)}