v3.0 Architecture

Separating the load engine to the set of the mini-services will dramatically improve the following:

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

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.

• 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.

• Item Generator

  The entity which reads a specified item input and pushes the resolved items to the load generator.

• I/O Task

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

Mini-Services

Storage Driver

The service 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 an extension of the Item Generator which generates the I/O tasks from the generated Items. The basic properties are:

• I/O type (create/read/etc)
• Item output generating new I/O tasks
• Relative weight for the Storage Drivers

Load Monitor

Basic functions:

• User interaction (optional)
• Configuration deployment
• Test initiation
• Execution control (timeouts handling, shutdown invocations, etc)
• Metrics aggregation and representation

Modes

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 Storage Driver is circular and the status of the I/O task is "success" then I/O task is put into the Storage Driver's own I/O tasks queue. Else 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 Monitor invokes the getResults method of the Storage Driver and get the next I/O task result.
14. The Load Monitor logs the corresponding I/O trace record if it is enabled.
15. The Load Monitor updates the performance metrics and internal counters using the I/O task result.
16. If circularity 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.

So the most basic item data flow looks like:

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