v3.6 Architecture

Basic Terms

• Storage

  A cloud storage or a filesystem

• Item

  While Storage is the subject of a load the Item is the object of a load. The only thing which item has is a mutable name.

• Data Item

  An Item with a data payload. Any Data Item has the corresponding size.

• Item Input

  The readable source of the items. This may be a CSV file, a binary stream, a collection or a bucket listing.

• Item Output

  The writable destination for the items. This may be a CSV file, a binary stream or a collection.

• I/O Task

  An I/O task is a item linked with a particular I/O type (write/read/delete). Also, any I/O Task has the state and the execution result as an extension of this state.

• Test

  Any separate Mongoose run.

• Test Step

  Test step is an unit of metrics reporting and test execution flow.

  For each test step:

  • total metrics are calculated and reported
  • limits are configured and controlled

  Some kinds of steps (chain/mixed/weighted) may have sub-steps.

• Scenario

  A set of test steps combined and organized using flow elements (sequential, parallel, chain, etc). Scenario is usually provided externally in a JSON file.

Components

Separating the load engine to the set of the components improves the following:

• Scalability
• Performance
• Reliability due to components isolation
• Extensibility due to lower dependency between the components

The load engine model consists of 4 major components.

Storage Driver

The service component which executes the I/O tasks generated by Load Generators. The basic property is the concurrency level and storage client configuration. The functionality includes:

• Low-level implementation of the I/O tasks execution functionality (FS either HTTP)
• Endpoint node balancer (if applicable)
• Rate limit related things
• Callbacks for the completed I/O Tasks

Load Generator

Load Generator is a component which generates the I/O tasks from the items got from the input. Many storage drivers may be associated with a load generator. The basic properties are:

• Origin Code (all I/O tasks generated share the same origin code)
• I/O type (create/read/etc)
• Shared rate throttle
• Shared weight throttle
• Storage drivers list
• Storage drivers balancer

Load Controller

A load controller is an unit of load step control. Many load generators may be associated with a load controller. Functionality:

• Configuration deployment
• Test initiation
• Execution control (timeouts handling, shutdown invocations, etc)

Load Monitor

Metrics aggregation and representation. The component is a singleton which was differentiated from the Load Controller component. Many load controllers may be associated with the single load monitor.

Modes

Note that the "circularity" (I/O task recycling) feature is represented in the arrow from the Load Controller to the Storage Driver.

A storage driver may be also a network service working on the remote host, which allows to perform a distributed load:

Sometimes it's needed to use common load execution control for different operation types. Using shared load controller for several different load generators is called "mixed load". "Weighted load" case is the variant of mixed load with configured weight throttle.

It's also possible to reuse the items immediately or after a configured delay in the "chain" mode:

Note that some modes may be combined easily. Mixed/weighted load and chain load work fine in the distributed mode. However combining the mixed load with chain load doesn't make much sense.

I/O Task Lifecycle

1. The Load Generator uses the configured item input and builds the next item.
2. The item is passed to I/O Task Builder by the Load Generator and the next I/O task is built.
3. If weight throttle is configured the I/O task awaits for the weight throttle permit.
4. If rate throttle is configured the I/O task awaits for the rate throttle permit.
5. The I/O task is put into the shared by the Load Monitor round-robin Storage Driver selector.
6. The I/O task is put into the selected Storage Driver.
7. The I/O task is enqueued into the Storage Driver's incoming I/O tasks queue.
8. If the Storage Driver has not enough own I/O tasks the next I/O task is taken from the incoming I/O tasks queue.
9. The I/O task is submitted for execution (the effect depends on the Storage Driver implementation).
10. The I/O task is completed and the ioTaskCompleted callback is invoked.
11. If the I/O task is composite get the list of the subtasks and put the to the own I/O tasks queue if these subtasks haven't been scheduled yet. Else if the I/O task is partial and parent (composite) I/O task has all subtasks (partial) done then put the parent I/O task into the own I/O tasks queue to schedule one more execution to finalize the composite I/O task execution (if necessary).
12. I/O task result is built and put into the I/O task results queue.
13. The Load Controller invokes the getAll method of the Storage Driver and get the next I/O task results.
14. The Load Controller logs the corresponding I/O trace record if it is enabled.
15. The Load Controller updates the performance metrics and internal counters using the I/O task result.
16. If recycling is configured the I/O task result corresponding item info record is put into the unique items map. Else if an item info output is configured the item info record is put to it.
17. If recycling is configured the I/O task result is sent again to the corresponding Storage Driver for the execution.

So the most basic item data flow looks like:

Item -> I/O Task -> I/O Task Result -> Item Info