-
Notifications
You must be signed in to change notification settings - Fork 12
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
ROX-21387: batch insert vulns #1345
Conversation
Images are ready for the commit at 748bc9e. To use the images, use the tag |
6cc4f18
to
748bc9e
Compare
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.
Amazing! 🥇
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.
LGTM, wondering if its worth running some queries against the DB just to double check that the # of vulns loaded before/after this fix are the same, and perhaps also query the table for total size / bytes consumed - if they are the same, ship it!
748bc9e
to
58d5753
Compare
I added a benchmark test for the offline dumps, too:
This also prints out the number of vulnerabilities we read from the JSON file, and they both match. I will merge with CI |
@RTann: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
58d5753
to
6e461eb
Compare
The batched implementation uses a little over half of the memory/op than the original implementation.
I also ran an experiment where I ran the current implementation and the implementation from this PR. In each separate cluster, I ran StackRox in offline-mode, and I uploaded the latest "offline" vuln dump to Central. From there I found the current implementation stayed at around 3.5G for about 20 minutes, while this PR's implementation hovered around 700MB for a few minutes before going back down to about 500MB, which is its steady-state. This is a rather significant memory reduction.