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

deserializeSafeFromHeader uses context.getHeader(headerName) instead of context.getHeaders() #2768

Merged
merged 2 commits into from
May 13, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,6 @@
package org.opensearch.security.support;

import java.io.Serializable;
import java.util.Map;

import com.google.common.base.Strings;

Expand Down Expand Up @@ -57,15 +56,8 @@ public static String getSafeFromHeader(final ThreadContext context, final String
return null;
}

String headerValue = null;

Map<String, String> headers = context.getHeaders();
if (!headers.containsKey(headerName) || (headerValue = headers.get(headerName)) == null) {
return null;
}

if (isInterClusterRequest(context) || isTrustedClusterRequest(context) || isDirectRequest(context)) {
return headerValue;
return context.getHeader(headerName);
}

Comment on lines -60 to 62
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is surprising that this small change makes a sizeable difference.

Copy link
Contributor Author

@parasjain1 parasjain1 May 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes are good - can you share the experiment results?

  • HeaderHelper.deserializeSafeFromHeader ‘s overall CPU usage dropped to 0.52% from 5%-12.5% seen across multiple CPU profiles obtained for prior runs.
  • Search Latency saw a drop of ~75%, Search Throughput increased by ~175%
  • Indexing Latency dropped by 70%, throughput increased by more than ~50%.

This was tested on a cluster running 3 m5.2xlarge data nodes with OS1.3

Results can vary based on the type of workload being executed.

return null;
Expand Down