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 scenarios that create lports usable with Rally runner for repetitions and parallelization #151

Open
jsitnicki opened this issue Feb 21, 2018 · 4 comments

Comments

@jsitnicki
Copy link
Contributor

Currently any scenario that involves port creation cannot be used with Rally serial or constant runner when number or repetitions (times) is greater than 1 and/or number of parallel runners (concurrency) is greater than 1, unless we ignore the fact that multiple ports will be assigned the same IP address.

We could address it either by picking IP addresses at random (from the subnet range) or keeping global state to track which is the next unassigned yet IP address from the pool.

Not using Rally runner for repetitions prevents us from getting a timing profile from Rally, i.e. duration over iterations for each atomic task. Example of such profile can be seen here:

https://people.redhat.com/jsitnick/ovn/create-and-bind-200-ports.html#/OvnNetwork.create_and_bind_ports/details

@jtaleric
Copy link

Another idea instead of random(), we could look at providing the scenario with a large subnet -- ie 192.168/16 -- then allowing the scenario to break this into /24s (or whatever the user passes).

This could be two additional fields we pass to the scenario -- allow the code to work as-is, but for people that want to take advantage of having concurrency,etc they pass these additional fields to get the benefit.

@l8huang
Copy link
Collaborator

l8huang commented Feb 23, 2018

Good thought. When it was implemented, I didn't find a good way for allocating subnet to rally tasks and ip to runners, the subnets used by tasks were planned statically. For setup 20K port as background pressure as fast as possible, we run multiple rally tasks concurrently.

If you are working on performance test and require to use parallel runners, could you please implement this feature? We(eBay SDN team) are working on OVN overlay scalability test recently, we are happy to review and may benefit from this feature as well.

@jsitnicki
Copy link
Contributor Author

@l8huang thanks for explaining why it was initially done like that. We're planning to work on it.

@l8huang
Copy link
Collaborator

l8huang commented Feb 27, 2018

Great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants