Test PR to measure accuracy and performance of Event size computation #17758
+9,724
−3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ues (heap dump, custom hashmaps navigator and CBOR serialization)
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
|
This pull request does not have a backport label. Could you fix it @andsel? 🙏
|
…ent size estimation
…tead of each invokation
💔 Build Failed
Failed CI Steps
History
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR is used to verify how Event memory estimation kinds varies, asked in #17736, respect to accuracy and performance.
All should be compared against a byte-perfect measure, ideally considering object headers and all the details about memory layout alignment covered by JOL library. However, the JOL library when used to compute the retained size of an event also consider the references down to the JRuby runtime, like hprof (heap dump files) does when analyzed with tools like Eclipse Memory Analyzer does. So determining what's the byte-perfect real size of an Event is not so obvious.
How the test is conducted?
Test fixtures
The test consider various form of events, regarding nesting of layers fields and size of the values assigned to each field.
I tested 3 sizes of values: 11 bytes, 512 and 2KB. Each event has 6 layers of nested maps with 10 elements in each node.
Another test was done with 2KB payload and quite flat event (2 layers only) with 10 keys each, to understand how the measures move reducing the nesting of events. I think having 6 layers of nested values could be an unusual case for a Logstash event.
Test structure
The test is composed of 2 halves:
Each run generates an heap dump, that was opened with Eclipse memory analyzer to calculate the retained size of the single
org.logstash.Eventpresent.Also the
JOLcomputed the retained size, which means that contains also the full JRuby runtime, because the event contains JRuby strings that has reference to the underlying JRuby classes.Size measures results
Values are in bytes, the variation in map navigation and cbor is calculated against the raw size.
Calculation benchmarks
Values are ops/second (higher better), the results are in ops/microsecond except for JOL which are in ops/second
Small set of benchmark executed running for 30 seconds:
Full set of benchmark executed running for 3 seconds:
Analysis of the results