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

Enhancements to Logstash Benchmarking Tool #10253

Merged
merged 6 commits into from Feb 28, 2019
Merged

Conversation

aagupta1
Copy link
Contributor

@aagupta1 aagupta1 commented Jan 7, 2019

Adding support for -

  1. Benchmarking custom Logstash config
  2. Outputting benchmarking stats for Memory usage

aagupta added 2 commits January 7, 2019 15:31
1. Custom Data Sets
2. Added heap used statistics to results
@elasticmachine
Copy link
Collaborator

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

@guyboertje
Copy link
Contributor

Jenkins please test this

@aagupta1
Copy link
Contributor Author

@jakelandis @original-brownbear Could you take a look at this PR. It contains changes to the logstash benchmarking tool to support custom configs. Also, made changes to output heap usage stats.

If you prefer, I can break these up into separate PR's. That would make it easier to review.

Copy link
Member

@original-brownbear original-brownbear left a comment

Choose a reason for hiding this comment

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

I think the idea here is good, we should allow inputting a custom config for sure!
I left two comments, but this should be reviewed by someone from the Logstash team now probably since I'm not on the LS team anymore.

@@ -32,7 +32,7 @@
public static final String TEST_CASE_PARAM = "testcase";

public static final String TEST_CASE_HELP =
"Currently available test cases are 'baseline' and 'apache'.";
"Currently available test cases are 'baseline', 'apache' and 'custom'.";
Copy link
Member

Choose a reason for hiding this comment

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

Maybe we should just remove this param and simply allow setting the new config param instead to simplify things a little?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could, do we not need to maintain backwards compatibility ?

Copy link
Member

Choose a reason for hiding this comment

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

Nah, I don't think so :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, in that case, can get rid of this param.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @original-brownbear, we need to support 3 types of configs / test cases -

  1. Baseline - This uses the logstash generator plugin to generate random input data. No config file is needed for this case.
  2. Apache - uses the sample apache config and a test data set downloaded from the provided url. Config file alone is not sufficient in this case, the data set is needed as well.
  3. Custom - Need path to the custom config to run benchmarking against.

So, for #1, we dont have the path to a config file to specify. For #2, we need to invoke a custom apache class that takes care of downloading the apache data set.

I can combine all three of the test cases above into a single input flag - "config". Config value would be "baseline", "apache" or path to a custom file.

cc @jakelandis @jsvd

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Went through the code again. Given the different handling required for the different test cases - baseline, apache and custom, I dont think it is a good idea to have a single config flag for all three, since the data type of the input will be different in each case.

See @jakelandis comments in this issue - "Add in an option for --testcase=custom and expose a --conifg-dir option such that, assuming I can figure out how to feed data in, I can use this for any test case."

@@ -0,0 +1,28 @@
input {
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we should ship this as a default test case since it requires a running Kafka instance with specific data in it for input and output.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense, will remove.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Have removed this file.

@aagupta1
Copy link
Contributor Author

@original-brownbear thanks for the review. Will make the changes, is there anyone on the logstash team that can review and approve the PR ?

@original-brownbear
Copy link
Member

pinging @jsvd for that :) Not sure who's handling this code now.

@aagupta1
Copy link
Contributor Author

@jsvd @original-brownbear @jakelandis Wondering if any of you could approve this PR ? @original-brownbear has already taken a first look at the changes, so this should not take long.

I'm excited for this to be my first logstash contribution, your time would be much appreciated !

Thanks in advance.

@danhermann
Copy link
Contributor

@aagupta1, this looks good to me apart from some minor code formatting issues. I opened a PR against your branch that fixes all those code formatting issues, so if you can incorporate that into this PR, I think we can merge it in.

@aagupta1
Copy link
Contributor Author

@danhermann, thanks very much for reviewing. Have approved your pull request. So, we can go ahead and merge this PR.

Copy link
Contributor

@danhermann danhermann left a comment

Choose a reason for hiding this comment

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

@aagupta1, I've gone ahead and merged it. Thanks for the contribution!

@danhermann danhermann merged commit 311ea14 into elastic:master Feb 28, 2019
jsvd pushed a commit that referenced this pull request Aug 29, 2019
* Adding support for -
1. Custom Data Sets
2. Added heap used statistics to results
jsvd pushed a commit that referenced this pull request Aug 29, 2019
* Adding support for -
1. Custom Data Sets
2. Added heap used statistics to results
andsel pushed a commit to andsel/logstash that referenced this pull request Sep 12, 2019
* Adding support for -
1. Custom Data Sets
2. Added heap used statistics to results
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants