-
Notifications
You must be signed in to change notification settings - Fork 7
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
[Feature] index stored_flows by cookie #41
[Feature] index stored_flows by cookie #41
Conversation
- Extracted check_consistency method
- Split _store_changed_flows into smaller specific methods
- Added more test coverage
- Avoided unecessary write in some cases for deletion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I just made a few comments to collaborate with the proposed solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! Thanks @viniarck for this great contribution!
Thank you both for reviewing. I'll merge this PR shortly. |
Fixes #34
Description of the change
Added
Changed
stored_flows
are now indexed by cookie, issue Adapt theflow_list
to store the flow states indexed bycookie
instead of OF commands. #34flow_persistence
data structured on storehouseDeprecated
flow_persistence
data structure isn't supported anymore. It's required to delete thekytos.flow.persistence
folder, upgrading won't be supported this time.Benchmark
I've run some executions to measure how long the consistency check was taking to confirm some speedups that we would expect and stressed tests with 500 flows on dpid 1 using cookies with a relative random distribution, by installing them and monitoring how long it was taking for the consistency checks to run:
In the execution below using the current
master
branch, you can see that the consistency check on00:00:00:00:00:00:00:01
was taking 6+ seconds, while the other switches that had fewer flows < 100ms:00:00:00:00:00:00:00:01
is always under < 100ms, and now we also have additional locks which trade off correctness for a bit of latency exec, I think in the future we can try do it in parallel once we can leverage a more powerful DB:Here's the confirmation of the 500+ stored flows: