-
Notifications
You must be signed in to change notification settings - Fork 552
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
audit: Reduce the number of memory allocations in the hotpath #16056
audit: Reduce the number of memory allocations in the hotpath #16056
Conversation
ss::httpd::const_req req, | ||
const ss::sstring& user, | ||
const ss::sstring& svc_name) { | ||
const auto activity_id = http_method_to_activity_id(req._method); |
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.
@michael-redpanda do we need the activity id to calculate the base hash? All that would matter is hashing the method I think. Then we could make this method private to utils.h again
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.
This I believe is for the API activity, yes? API activity includes both HTTP and Kafka. Kafka doesn't have a 'method' field. So yes, I believe we do need to use activity ID in the hash. You should double check, but does "type_id" of the base type get hashed? If so then "activity_id" is already being hashed as Type ID is a combination of class ID and activity ID (https://schema.ocsf.io/1.0.0/classes/api_activity?extensions= look towards the bottom).
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.
Yeah for sure, i was just wondering if it would be good enough to has something like 0 - 5, one value for each of the potential HTTP method types, instead of having to get one of 5 stringified versions of the enum to later just hash
I think it might also be worth it adding an additional find/replace commit to change the name of the |
721cc98
to
acabea1
Compare
Changes in force-push
|
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.
Thanks for looking into this.
Had a look and approach seems good. It seems like we are hashing quite a bit more now but maybe this is just an impression. Hashing was already quite visible before so want to make sure we are as smart as possible there.
Will leave to enterprise for a more thorough review.
Thanks for taking a look! We should be hashing the same amount as in the current impl since the hash function is called at the top of |
acabea1
to
ee41562
Compare
Changes in force-push
|
ee41562
to
28b117d
Compare
Changes in force-push
|
28b117d
to
c38c3d6
Compare
Change in force-push
|
c38c3d6
to
bed02c9
Compare
Changes in force-push
|
bed02c9
to
324f5d2
Compare
new failures in https://buildkite.com/redpanda/redpanda/builds/43691#018cfec8-1b3f-4b54-a5d6-8864b63b3835:
|
324f5d2
to
e893eca
Compare
e893eca
to
0fa2d02
Compare
- That way auditing can hash these types to quickly get a hash code of a larger ocsf type that encapsulates these acl options.
- This will be useful in future commits where a type can be passed to a templated method and static polymorphic dispatch can be used to determine which builder method to choose to construct the type
0fa2d02
to
8af1348
Compare
/backport v23.3.x |
With auditing enabled, high traffic events and low batch intervals it was observed that auditing was using more of the CPU then expected. This was traced back to many string conversions / string interpolation events when constructing an audit event.
An audit event is constructed at every possible attempt to enqueue the event so a hash code can be calculated. In the event the message has been determined it is a duplicate, the event can be deallocated, but this is wasteful. The event should only be constructed if it unique, to avoid the expensive serialization performed.
This pull request modifies the control flow in the audit log manager to calculate a hash code for the ocsf event without constructing the event itself. Since event construction depends on these parameters anyway, an appropriately unique hash code can be calculated with a free function using these parameters as input. In the event the hash code is unique, then the event will be allocated.
Linking to issue: #15898
Backports Required
Release Notes
Improvements