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

Make client execution more flexible #236

Closed
cdahlqvist opened this issue Feb 21, 2017 · 4 comments
Closed

Make client execution more flexible #236

cdahlqvist opened this issue Feb 21, 2017 · 4 comments
Labels
enhancement Improves the status quo :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

Comments

@cdahlqvist
Copy link
Contributor

If I configure a task in a schedule to run once every 10 seconds using 2 clients (as in example below), e.g. in order to be able to execute the correct number of operations during the benchmark even if the service time starts to exceed 10 seconds, it seems like both clients issue a request at the same every 20 seconds.

{
  "operation": "index-append-1000",
  "warmup-time-period": 0,
  "time-period": 600,
  "target-interval": 10,
  "clients": 2
}

It would be useful to have the option to be able to stagger, or even randomize, the initial starting time for each client so that requests would get spread out.

@danielmitterdorfer danielmitterdorfer added this to the 0.5.1 milestone Feb 22, 2017
@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 Feb 22, 2017
@danielmitterdorfer danielmitterdorfer modified the milestones: 0.5.1, 0.5.2, 0.5.3 Mar 1, 2017
@danielmitterdorfer
Copy link
Member

I tend to close this one in favor of #251. Because if you have a non-uniform request distribution anyway I doubt that you still care about what happens at the first request which is usually during the warmup phase (and after that clients will not issue requests at exactly the same time in the general case due to the non-uniform distribution).

@danielmitterdorfer
Copy link
Member

Closing in favor of #251 as it will allow users to specify arbitrarily complex scheduling strategies.

@danielmitterdorfer danielmitterdorfer removed this from the 0.5.3 milestone Mar 31, 2017
@cdahlqvist
Copy link
Contributor Author

I still think this is valuable as it allows spreading out requests over time without having to write a scheduler (it would still be hard to coordinate multiple processes through a scheduler).

@danielmitterdorfer
Copy link
Member

danielmitterdorfer commented Apr 3, 2017

I still think this is valuable

With the new scheduler implementations you can already randomize right from the beginning. Here is an example that shows how different scheduling strategies behave that I've already implemented:

schedulers_10s

It just shows the first ten seconds and both strategies have been configured for a target throughput of 1 operation per second. Rally has used the "deterministic" scheduling strategy so far. "Poisson" is a new distribution and you can already see that the problem that clients will issue requests always at exactly the same time will not happen anymore.

it would still be hard to coordinate multiple processes through a scheduler

There will be no global coordination - even with a scheduler. The "master" load driver actor will attempt to start all clients at the same time. A scheduler instance is bound to one client and decides locally when to issue the next request (and depending on the scheduler implementation this will be at different times for different clients).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improves the status quo :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

2 participants