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

chore(logging): add detectResource benchmark #6084

Merged
merged 1 commit into from
May 24, 2022

Conversation

minherz
Copy link
Contributor

@minherz minherz commented May 24, 2022

Adding a benchmark test to measure execution time for detectResource() to address #5855.
Current implementation uses cloud.google.com/go/compute/metadata package to read Google Cloud metadata server attributes. The package implements retrying mechanism to cover on occasional problems of miscommunication with the metadata server. When a new Logger instance is being created, it calls detectResource() to read the monitored resource object. The resource detection algorithm is invoked once per process (regardless of how many Logger instances is created). The algorithm checks whether the environment runs the metadata server as a first step and to avoid further validations. Due to the retrying mechanism, this call may take between 6 to 7 seconds which composes the overall delay of creating a first instance of the Logger.
The benchmark demonstrates that only first Logger takes long time:

go test -run=XXX -bench=BenchmarkDetectResource -benchtime 8s
goos: linux
goarch: amd64
pkg: cloud.google.com/go/logging
cpu: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
BenchmarkDetectResource-8       1000000000               2.291 ns/op
PASS
ok      cloud.google.com/go/logging     9.955s

When the cloud.google.com/go/compute/metadata package will be modified to allow customizable retrying mechanism, this logic will be altered to minimize the number of retries for the initial call.

@minherz minherz requested review from a team as code owners May 24, 2022 02:53
@product-auto-label product-auto-label bot added size: s Pull request size is small. api: logging Issues related to the Cloud Logging API. labels May 24, 2022
@minherz minherz merged commit 934dd7e into structured_logging May 24, 2022
@minherz minherz deleted the minherz/add-detect-resource-benchmark branch May 24, 2022 03:54
minherz added a commit that referenced this pull request May 24, 2022
Adding a benchmark test to measure execution time for detectResource() to address #5855.
Current implementation uses cloud.google.com/go/compute/metadata package to read Google Cloud metadata server attributes. The package implements retrying mechanism to cover on occasional problems of miscommunication with the metadata server. When a new Logger instance is being created, it calls detectResource() to read the monitored resource object. The resource detection algorithm is invoked once per process (regardless of how many Logger instances is created). The algorithm checks whether the environment runs the metadata server as a first step and to avoid further validations. Due to the retrying mechanism, this call may take between 6 to 7 seconds which composes the overall delay of creating a first instance of the Logger.
The benchmark demonstrates that only first Logger takes long time:

```bash
go test -run=XXX -bench=BenchmarkDetectResource -benchtime 8s
goos: linux
goarch: amd64
pkg: cloud.google.com/go/logging
cpu: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
BenchmarkDetectResource-8       1000000000               2.291 ns/op
PASS
ok      cloud.google.com/go/logging     9.955s
```

When the  cloud.google.com/go/compute/metadata package will be modified to allow customizable retrying mechanism, this logic will be altered to minimize the number of retries for the initial call.
minherz added a commit that referenced this pull request May 25, 2022
Adding a benchmark test to measure execution time for detectResource() to address #5855.
Current implementation uses cloud.google.com/go/compute/metadata package to read Google Cloud metadata server attributes. The package implements retrying mechanism to cover on occasional problems of miscommunication with the metadata server. When a new Logger instance is being created, it calls detectResource() to read the monitored resource object. The resource detection algorithm is invoked once per process (regardless of how many Logger instances is created). The algorithm checks whether the environment runs the metadata server as a first step and to avoid further validations. Due to the retrying mechanism, this call may take between 6 to 7 seconds which composes the overall delay of creating a first instance of the Logger.
The benchmark demonstrates that only first Logger takes long time:

```bash
go test -run=XXX -bench=BenchmarkDetectResource -benchtime 8s
goos: linux
goarch: amd64
pkg: cloud.google.com/go/logging
cpu: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
BenchmarkDetectResource-8       1000000000               2.291 ns/op
PASS
ok      cloud.google.com/go/logging     9.955s
```

When the  cloud.google.com/go/compute/metadata package will be modified to allow customizable retrying mechanism, this logic will be altered to minimize the number of retries for the initial call.
minherz added a commit that referenced this pull request May 28, 2022
Adding a benchmark test to measure execution time for detectResource() to address #5855.
Current implementation uses cloud.google.com/go/compute/metadata package to read Google Cloud metadata server attributes. The package implements retrying mechanism to cover on occasional problems of miscommunication with the metadata server. When a new Logger instance is being created, it calls detectResource() to read the monitored resource object. The resource detection algorithm is invoked once per process (regardless of how many Logger instances is created). The algorithm checks whether the environment runs the metadata server as a first step and to avoid further validations. Due to the retrying mechanism, this call may take between 6 to 7 seconds which composes the overall delay of creating a first instance of the Logger.
The benchmark demonstrates that only first Logger takes long time:

```bash
go test -run=XXX -bench=BenchmarkDetectResource -benchtime 8s
goos: linux
goarch: amd64
pkg: cloud.google.com/go/logging
cpu: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
BenchmarkDetectResource-8       1000000000               2.291 ns/op
PASS
ok      cloud.google.com/go/logging     9.955s
```

When the  cloud.google.com/go/compute/metadata package will be modified to allow customizable retrying mechanism, this logic will be altered to minimize the number of retries for the initial call.
minherz added a commit that referenced this pull request Jun 10, 2022
Adding a benchmark test to measure execution time for detectResource() to address #5855.
Current implementation uses cloud.google.com/go/compute/metadata package to read Google Cloud metadata server attributes. The package implements retrying mechanism to cover on occasional problems of miscommunication with the metadata server. When a new Logger instance is being created, it calls detectResource() to read the monitored resource object. The resource detection algorithm is invoked once per process (regardless of how many Logger instances is created). The algorithm checks whether the environment runs the metadata server as a first step and to avoid further validations. Due to the retrying mechanism, this call may take between 6 to 7 seconds which composes the overall delay of creating a first instance of the Logger.
The benchmark demonstrates that only first Logger takes long time:

```bash
go test -run=XXX -bench=BenchmarkDetectResource -benchtime 8s
goos: linux
goarch: amd64
pkg: cloud.google.com/go/logging
cpu: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
BenchmarkDetectResource-8       1000000000               2.291 ns/op
PASS
ok      cloud.google.com/go/logging     9.955s
```

When the  cloud.google.com/go/compute/metadata package will be modified to allow customizable retrying mechanism, this logic will be altered to minimize the number of retries for the initial call.
minherz added a commit that referenced this pull request Jun 23, 2022
Adding a benchmark test to measure execution time for detectResource() to address #5855.
Current implementation uses cloud.google.com/go/compute/metadata package to read Google Cloud metadata server attributes. The package implements retrying mechanism to cover on occasional problems of miscommunication with the metadata server. When a new Logger instance is being created, it calls detectResource() to read the monitored resource object. The resource detection algorithm is invoked once per process (regardless of how many Logger instances is created). The algorithm checks whether the environment runs the metadata server as a first step and to avoid further validations. Due to the retrying mechanism, this call may take between 6 to 7 seconds which composes the overall delay of creating a first instance of the Logger.
The benchmark demonstrates that only first Logger takes long time:

```bash
go test -run=XXX -bench=BenchmarkDetectResource -benchtime 8s
goos: linux
goarch: amd64
pkg: cloud.google.com/go/logging
cpu: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
BenchmarkDetectResource-8       1000000000               2.291 ns/op
PASS
ok      cloud.google.com/go/logging     9.955s
```

When the  cloud.google.com/go/compute/metadata package will be modified to allow customizable retrying mechanism, this logic will be altered to minimize the number of retries for the initial call.
minherz added a commit that referenced this pull request Jun 25, 2022
Adding a benchmark test to measure execution time for detectResource() to address #5855.
Current implementation uses cloud.google.com/go/compute/metadata package to read Google Cloud metadata server attributes. The package implements retrying mechanism to cover on occasional problems of miscommunication with the metadata server. When a new Logger instance is being created, it calls detectResource() to read the monitored resource object. The resource detection algorithm is invoked once per process (regardless of how many Logger instances is created). The algorithm checks whether the environment runs the metadata server as a first step and to avoid further validations. Due to the retrying mechanism, this call may take between 6 to 7 seconds which composes the overall delay of creating a first instance of the Logger.
The benchmark demonstrates that only first Logger takes long time:

```bash
go test -run=XXX -bench=BenchmarkDetectResource -benchtime 8s
goos: linux
goarch: amd64
pkg: cloud.google.com/go/logging
cpu: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
BenchmarkDetectResource-8       1000000000               2.291 ns/op
PASS
ok      cloud.google.com/go/logging     9.955s
```

When the  cloud.google.com/go/compute/metadata package will be modified to allow customizable retrying mechanism, this logic will be altered to minimize the number of retries for the initial call.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: logging Issues related to the Cloud Logging API. size: s Pull request size is small.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant