Load flow control

[timofeevmd]

I want to be able

• control the number of load threads
• test duration
• control the execution of the script depending on the status of the transaction code using command line arguments.

It must be passed parameters:

• number of threads
• delay (in seconds)
• time for which the number of threads should be entered (ramp-up) (in seconds)
• stage operation time (in seconds)

• the time for which it is necessary to remove the flows from the work of this stage This set of parameters will describe only 1 stage of the overall load model. When adding a second stage, the parameters must be duplicated

  • the behavior of the thread when receiving an error
    • send the next request despite the received error
    • start the next iteration
    • stop the current thread
    • stop the test completely

use cases:

1. The load model is stepped. (load model) 1.1. at the beginning of the test, I put 10 threads into operation, which continue to work cyclically during the test 1.2. In 10 minutes I want to enter 14 more threads within 20 seconds. They will work until the test time is 10 seconds. And I take these threads out of work within 10 seconds

2. flow control depending on the event 2.1. During the test, 1 thread receives the status code 200OK - the thread will not interrupt its work until an error message is received When an error is received, the script continues to work in accordance with the parameter passed on the command line

   ### Tasks
   - [ ] https://github.com/soramitsu/iroha2-longevity-load-rs/issues/71
   - [ ] https://github.com/soramitsu/iroha2-longevity-load-rs/issues/72
   - [ ] https://github.com/soramitsu/iroha2-longevity-load-rs/issues/73

[pesterev]

Let's use the term Operation. This tool completely asynchronous and concurrent, so we don't need use threads directly to execute operations concurrently. My suggestion is to increase number of concurrently operations (not threads) based on your algorithm (flow control).

[timofeevmd]

OK, If I understood everything correctly, we will have 1 thread with asynchronous execution

use case Load scenario - sequential execution of transactions, while the execution of the second transaction depends on the result of the first one. I am running the first load step in 10 operations. 1 operation - 1 virtual user. In the first thread, the first operation receives statusCode 500 in response I want to interrupt the execution of this operation and start the loop again for this operation only

Question - will it be possible to interrupt only 1 operation without interrupting the work of the remaining 9?

[pesterev]

Question - will it be possible to interrupt only 1 operation without interrupting the work of the remaining 9?

Technically it's not hard to implement. The main problem is describing these sequential and/or not sequential operations. It will be like a scenario of how to execute these operations in some file, or you want to specify them in CLI parameters, how will it look like?

Do you have examples of the usage alternatives tools with the same or similar features?

[timofeevmd]

as a rule, scenarios in the load are compiled identically to the user's work scn_1{ transaction_0 assertByTransaction_0 transaction_n assertByTransaction_n transaction_n+1 assertByTransaction_n+1 } but it is also possible to build on the basis of the most frequently used operations, provided that none of the operations in the scenario is interconnected

it is possible to pass arguments from outside to the script

source /path/to/jmeter/jmeter.sh // jmeter start -n -t /mnt/jmeter/$(TEST).jmx // path to test.jmx scenario -JVUSERS=$(VUSERS) //external arg -JRAMP_UP=$(RAMP_UP) -JTHINK_TIME=$(THINK_TIME) -JTHINK_TIME_DEVIATION=$(THINK_TIME_DEVIATION) -JDURATION=$(DURATION) -JENVIRONMENT=$(ENV_URL)

[timofeevmd]

to run load testing offers the implementation of a simpler operation control mechanism

Control mechanism depending on the status of the received operation

• Ability to control the scenario depending on the result of the operation

  • Continue: send the next request despite the error received
  • Start next work cycle: start next iteration
  • Stop operation: stop the current operation
  • Stop test: completely stop the test

• Test parameterization:

  • Number of operations
  • The time for which all transactions will be entered (in seconds)

• As well as optional parameters:

  • Number of iterations
  • Test duration (in seconds)