I have noticed execution time for simple Condition and ForEach actions in my Logic Apps has an peculiarly long run-time, even considering the scope of these actions taking into account all downstream actions.
In a simple case, my deepest scope action is a For Each:
Notice the For Each is a short as possible in number of iterations: only one record being processed. Each action inside is very brief. The two HTTP actions are 52 ms total:
The Set Variable action is 29 ms:
How am I to understand this sums up to 1.63 seconds in the For Each?
This seems very odd to me, even with the "scope" context of considering ForEach reporting on all downstream actions. It still feels like well over 1.6 seconds that should not be needed.
There will always be some overhead for scopes (delta for the foreach job to wake up + read and aggregate action results + persist state).
There are changes you can make to optimize this, for example, if an array data is coming in from the trigger, "split-on" the array and have separate run process each item will have a better performance than "not-split on" and loop over the array using for-each.
Related
I have 250 users ,and around 60000 sample counts should be hit including all the requests. Whichever request is supposed to get huge sample count,I have put those request within loop count,But the requests outside the loop are getting executed only 3-4 times which is less than expected. How do I handle this?
It is not very possible to provide the comprehensive answer without knowing what you're trying to achieve and seeing your test or at least Thread Group configuration
The easiest option is moving the requests which you want to execute more times into a separate Thread Group
If the requests have to stay in one Thread Group you can control the frequency using Throughput Controller
If the logic is more complex - consider using Switch Controller or Weighted Switch Controller
I am doing load testing for one ecommerce website. I am using Ultimate thread group.
Now I want to send per user only 1 request. So for ex: If 500 users then only 500 request should send. How can I achieve it using Ultimate thread group?
Why I want above because I am doing whole process like login, select product, add to cart and checkout. So it should do everything only once per user.
Your test design is a little bit flaky as given each user does login, select product, add to cart and checkout you will have at least 4 requests per user which gives 2000 requests in total (doesn't include embedded resources calls). You can use Transaction Controller to group these requests into one "workflow" however it won't limit actual amount of requests.
If you need to run your workflow by each user only once you may run into a situation when either load will be less than 500 concurrent users or test duration will be less than 30/60 minutes, see JMeter Test Results: Why the Actual Users Number is Lower than Expected
If you add more iterations each user will be executing your workflow more than once
Normally web test plan should look as follows:
Given each user executes test scenario steps and acting like a real user
Gradually increase the number of users unless application response time becomes too high or errors start occurring, whatever comes the first
Analyze results, identify the bottleneck, report your findings
Lets say the duration of the test is 1 hour. First user completes the workflow you had mentioned in the first 10 mins itself. What should happen after the workflow for the user? Should the thread be idle for the remaining 50 mins?
I think you should use the regular Thread Group with 500 threads and loop count as 1. Ultimate Thread Group is for duration based tests. You could use Once Only Controller as a workaround inside to do the action only once for the user. But it is an ugly approach.
You can use Throughput Controller.
The Throughput Controller allows the user to control how often it is executed. There are two modes:
percent execution
total executions
Percent executions
causes the controller to execute a certain percentage of the iterations through the test plan.
Total executions
causes the controller to stop executing after a certain number of executions have occurred.
Like the Once Only Controller, this setting is reset when a parent Loop Controller restarts.
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
The documentation says: "task_group class represents a collection of parallel work which can be waited on or canceled."
1). Do I take it to mean that tasks need to be logically related (but broken down) and that you will ideally need to wait on them elsewhere to collate the results?
IOW, is it possible to use task_group to just schedule asynchronous tasks that basically have no relation to each other (as an analogy: sort of like dumping each iteration of some processing activity in a queue and picking it up for execution by another thread)? Each of them just execute and die away and as a result I wouldn't even have to wait or cancel them.
(I do understand that the task_group dtor will throw an exception if I don't cancel or wait on incomplete tasks. Lets forget that for the moment and only focus on whether I am using it for the right purpose).
This page has an explanation on task groups - not bad.
In a nutshell,
use task groups (the concurrency::task_group class or the concurrency::parallel_invoke algorithm) when you want to decompose parallel work into smaller pieces and then wait for those smaller pieces to complete.
I am designing a cloud app and need a worker process which scours my database looking for work, and then performs it.
Most of the info I seem to find on the subject of background tasks in the cloud involves some kind of scheduler and/or queuing system.
What I have doesn't quite fit into the "run this task every 5 minutes" or "add this to the queue to be executed later" models. I think the main difference to my problem is that the workers themselves find work to do, rather than being assigned it by a periodic scheduler or an external process that generates work.
What I have is basically a giant table where each entry has three fields:
job: a small task to be performed, lets say it gets the last message from a twitter account and stores it in the database
the interval at which to perform that job: say every 5 minutes, N.B. the interval is arbitrary and different for each entry in the table
the last date when the job was performed
The way I would implement this is to have a worker which has an infinite loop. When it enters the loop, it scours the database a)looking for items whose date + interval < currentTime, b)when it finds one, it sets date = currentTime, and c)then executes the job. If there is no work ATM, it sleep for a few seconds, then tries again.
I will have many parallel workers scouring the database simultaneously, which is why I do b) first and then c) in the paragraph above. Since there are parallel workers, action a) and b) are atomic operations on the database to prevent work being duplicated. If the worker crashes after a) and b), but before it manages to finish the work, it's no big deal, and the workers can just do it at the next interval; reason for this is that the work is not performed in a time-invariant system so a backlog scenario of failed jobs has no benefit as the tasks have to be performed at their exact intervals, so it's better to skip 1 interval than to have uneven intervals between which the tasks were executed.
My question is whether that is a reasonable implementation strategy? If so, how do I bring this process to life on the cloud (I am using Heroku, but may switch to EC2 in the future)? I still haven't written any code so I would welcome other suggestions (maybe I misunderstood the use cases/applications for queue systems).
This sounds so close to using something like a scheduled job that you might as well tread the well beaten path and do it the more conventional way. There's no reason why you can't schedule a job to run once every few seconds.
However, this idea of looking for work sounds dodgy. What happens if two workers find the same task to run at the same time for instance? Also, are there not triggers in the application which can indicate that work needs doing? It seems strange that you have code 'looking for work'.
You can go a very long way with simple periodic background tasks, so I would exhaust all possibilities in that area before rolling your own.