What is the purpose of setting the loop count? Is it just depend on how many times i want to run the test? Or it has other purpose of test with different loop count? Will it affect the final test result?
"If you give loop count as 2 then every request two times to the server"
I found this online, but i don't understand what it means.
Based on my understanding, the loop count set to 2 because of i want to repeat the test twice only. After the first test end, then the threads in first round test in dead before the second test starts. Then the new thread group will send the request to the server. Why "every request two times to the server"?
The loop count means each thread of your thread group will run the steps inside the loop twice if iteration is set to 2
The thread will start based on delay and rampup and not related to this setting
If your server has concurrent users limit, for example 100, and you want to execute more, as 600, you can set loop count as 6 and execute 600 requests with given server limits
It's the number of times for each JMeter thread (virtual user) to execute Samplers inside the Thread Group
Each JMeter thread executes Samplers upside down (or according to the Logic Controllers) so if there are no more Samplers to execute the thread will shut down. And it might be the case you won't be able to achieve the desired concurrency because some threads have already finished execution and some haven't been yet started like it's described in the JMeter Test Results: Why the Actual Users Number is Lower than Expected so you might want to increase the number of iterations or even set it to "Infinite" and control the test duration using "Duration" section of the Thread Group or Runtime Controller
Related
I have 5 thread groups each one have 3 api requests and each thread should execute one after one, in 1 hour load test should achieve 120 hits per second.
Pacing: 5 sec
Thinktime: 8 sec
Each thread single iteration time: 20 sec
So for this how much users I need to give to achieve required 120 hits per second and how can I do load test for 5 thread groups because each one should execute one after one.
It's a matter of simple arithmetic calculations and I believe question should go to https://math.stackexchange.com/ (or alternatively you can catch a student of the nearest school ask ask him)
Each thread single iteration time: 20 sec
means that each user executes 3 requests per 20 seconds, to wit 1 request per 6.6 seconds.
So you need 6.6 users to get 1 request per second or 792 users to reach 120 requests per second.
Also "pacing" concept is for the the "dumb" tools which don't support setting the desired throughput and JMeter provides:
Constant Throughput Timer
Precise Throughput Timer
Throughput Shaping Timer
any of them provides possibility to define the number of requests per second, especially the latter one which can be connected with Concurrency Thread Group
I need to conduct a series of database performance tests using jMeter.
The database has ~32m accounts, and ~15 billion transactions.
I have configured a JDBC connection configuration and a JDBC request with a single SELECT statement and a hardcoded vAccountNum and this works fine.
SELECT col1,col2,col3,col4,col5 from transactions where account=vAccountNum
I need to measure how many results sets can be completed in five minutes for 1 session; then add sessions and tune until server resources are exhausted.
What is the best way to randomize vAccountNum so that I can get an equal distribution of accounts returned?
Depending on what type vAccountNum is the choices are in:
Various JMeter Functions like
__Random function - to generate random number within defined range
__threadNum function - returns current thread's number (1 for first thread, 2 for second, etc.)
__counter function - a simple counter which is being incremented by 1 each time it is called
CSV Data Set Config - to read pre-defined vAccountNum values from CSV file. In that case make sure that you provide enough account numbers so you won't be hammering the server with the same query which likely to be returned from cache.
I need to perform some queries on a rather large table, how do i check if the query has finished?
The main problem is that the queries can take up to 10 minutes and i want to tell the user, and hence the webbrowser, that its still running, so simply waiting for $sth->fetch* to finish is not an option as it will "pause" the script until there is data to be fetched.
I checked the documentation but there seems to be no function like $dbh->has_finished() or $dbh->has_data().
Asynchronous database queries should be possible with an event loop. I suggest that you take a look at AnyEvent::DBI. The trick is to use a condition variable. The query is executed asynchronously. When the query is finishen it calls a callback sub that broadcasts on the condition variable. You can use $cv->ready for checking whether the query is finished.
My production environment now has a good number of triggers and classes. These all work great and are functioning as they should. However, I am unable to deploy a couple of new triggers because the test classes are calling too many future methods. I assure you that my code is bulkified so as to only call a future method one time per run. However, when a trigger is being deployed through the IDE, every test is run and as a result the future calls are being run too many times.
I have tried places a try/catch around all of my future calls hoping that if it did hit the limit it would just route to the catch method. It still fails the deployment though with the same error.
The main future call that I am making is only reference-able through one class. It is an HTTP call which pings my website.
Are there any methods to avoid this limit, short of completely re-doing all of my test classes? As you can see below, the excess future calls are occurring on (default) and not on a specific trigger.
10:39:15.617|LIMIT_USAGE_FOR_NS|(default)|
Number of SOQL queries: 85 out of 100 ******* CLOSE TO LIMIT
Number of query rows: 1474 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 19 out of 150
Number of DML rows: 23 out of 10000
Number of script statements: 2370 out of 200000
Maximum heap size: 0 out of 6000000
Number of callouts: 0 out of 10
Number of Email Invocations: 0 out of 10
Number of fields describes: 0 out of 100
Number of record type describes: 0 out of 100
Number of child relationships describes: 0 out of 100
Number of picklist describes: 0 out of 100
Number of future calls: 11 out of 10 ******* CLOSE TO LIMIT
Without looking at the specific code, it is difficult to tell what paths are causing you to reach the future calls limit during testing. It would be worth exploring why the components in the current deployment are hitting the future method limit.
If your objective is to get the tests to pass, you could use a combination of Test.isRunningTest(), Limits.getFutureCalls() and Limits.getLimitFutureCalls() so that the future methods aren't invoked during testing when they would otherwise cause the limit to be exceeded.
E.g.
if(Test.isRunningTest() && Limits.getFutureCalls() >= Limits.getLimitFutureCalls()) {
system.debug(LoggingLevel.Error, 'Future method limit reached. Skipping...');
} else {
callTheFutureMethod();
}
I have a large task that proceeds in several major steps: Step A must complete before Step B can be started, etc. But each major step can be divided up across multiple processes, in my case, using Delayed::Job.
The question: Is there a simple technique for starting Step B only after all the processes have completed working on Step A?
Note 1: I don't know a priori how many external workers have been spun up, so keeping a reference count of completed workers won't help.
Note 2: I'd prefer not to create a worker whose sole job is to busy wait for the other jobs to complete. Heroku workers cost money!
Note 3: I've considered having each worker examine the Delayed::Job queue in the after callback to decide if it's the last one working on Step A, in which case it could initiate Step B. This could work, but seems potentially fraught with gotchas. (In the absence of better answers, this is the approach I'm going with.)
I think it really depends on the specifics of what you are doing, but you could set priority levels such that any jobs from Step A run first. Depending on the specifics, that might be enough. From the github page:
By default all jobs are scheduled with priority = 0, which is top
priority. You can change this by setting
Delayed::Worker.default_priority to something else. Lower numbers have
higher priority.
So if you set Step A to run at priority = 0, and Step B to run at priority = 100, nothing in Step B will run until Step A is complete.
There's some cases where this will be problematic -- in particular, if you have a lot of jobs and are running a lot of workers, you will probably have some workers running Step B before the work in Step A is finished. Ideally in this setup, Step B has some sort of check to make check if it can be run or not.