Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distribute load-test driver #257

Closed
danielmitterdorfer opened this issue Apr 5, 2017 · 1 comment
Closed

Distribute load-test driver #257

danielmitterdorfer opened this issue Apr 5, 2017 · 1 comment
Labels
enhancement Improves the status quo highlight A substantial improvement that is worth mentioning separately in release notes :Load Driver Changes that affect the core of the load driver such as scheduling, the measurement approach etc. :Track Management New operations, changes in the track format, track download changes and the like
Milestone

Comments

@danielmitterdorfer
Copy link
Member

danielmitterdorfer commented Apr 5, 2017

At the moment, Rally can apply load only from one machine. This is fine for smaller clusters but if we want to benchmark larger ones, we want to apply load from more than one machine. Hence, we need to distribute the load test driver.

Design

Rally's internal design uses the actor approach and is already suited for distribution (we already did it with ES provisioning). At the moment we have one global Driver actor that runs on the coordinating node (this is the node where the user invokes esrally on the command line) and one LoadGenerator actor per client.

Rally will attempt to balance clients across all machines that are provided by the user, i.e. if the track defines that we need to run 8 clients and the user provides 4 machines, we will run two clients on each machine (clients will be assigned round-robin to machines). This may lead to hot-spots but we should start simple.

Upon startup, the coordinating Driver will launch one TrackPreparationActor per host. This actor will take care of tasks that need to be done once per machine. These tasks are mainly on track management side (e.g. checking out the right version of a track or downloading benchmark data). In the first step we will not attempt to optimize downloading of benchmark data; to be precise: every machine will download all benchmark data for the track that is run.

After the track is prepared, these actors are shutdown and load generation is coordinated by the Driver (as is). Clients get assigned to machines in a round-robin fashion.

@danielmitterdorfer danielmitterdorfer added :Load Driver Changes that affect the core of the load driver such as scheduling, the measurement approach etc. :Track Management New operations, changes in the track format, track download changes and the like enhancement Improves the status quo labels Apr 5, 2017
@danielmitterdorfer danielmitterdorfer added this to the 0.5.x milestone Apr 5, 2017
danielmitterdorfer added a commit that referenced this issue Apr 5, 2017
@danielmitterdorfer danielmitterdorfer added the highlight A substantial improvement that is worth mentioning separately in release notes label Apr 5, 2017
@danielmitterdorfer
Copy link
Member Author

Reminder: We should keep #261 in mind, because this will not work with a queue-based actor system (which we use when the actor system cannot determine a valid socket address).

@danielmitterdorfer danielmitterdorfer modified the milestones: 0.6.x, 0.7.x Aug 9, 2017
@danielmitterdorfer danielmitterdorfer self-assigned this Aug 17, 2017
@danielmitterdorfer danielmitterdorfer modified the milestones: 0.7.1, 0.7.x Aug 17, 2017
danielmitterdorfer added a commit that referenced this issue Aug 21, 2017
danielmitterdorfer added a commit that referenced this issue Aug 21, 2017
@danielmitterdorfer danielmitterdorfer removed their assignment Aug 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improves the status quo highlight A substantial improvement that is worth mentioning separately in release notes :Load Driver Changes that affect the core of the load driver such as scheduling, the measurement approach etc. :Track Management New operations, changes in the track format, track download changes and the like
Projects
None yet
Development

No branches or pull requests

1 participant