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

gcp-observability: Fixed slowness for GcpObservabilityTest.enableObservability test case #11783

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

harshagoo94
Copy link

@harshagoo94 harshagoo94 commented Dec 26, 2024

gcp-obsrevability : Fixed the slowness issue for GcpObservabilityTest.enableObservability test case.

Fixes #10146.

Snippet before fix as execuation time taking 1m 21sec

10146-before-fix

Snippet after fix as execuation time taking below 1sec 44msec.

10146-after-fix

@harshagoo94 harshagoo94 marked this pull request as ready for review December 26, 2024 07:54
@shivaspeaks shivaspeaks added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Dec 26, 2024
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Dec 26, 2024
Copy link
Member

@shivaspeaks shivaspeaks left a comment

Choose a reason for hiding this comment

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

If this is the problem then should we do same in line 233 in original code or 236 after your commit as well? It has the same try-with-resource block usage and I don't see anywhere in grpc-java anything similar like this.

@shivaspeaks shivaspeaks requested a review from ejona86 December 26, 2024 09:42
@harshagoo94
Copy link
Author

If this is the problem then should we do same in line 233 in original code or 236 after your commit as well? It has the same try-with-resource block usage and I don't see anywhere in grpc-java anything similar like this.

@shivaspeaks ,

As I have observed, enabling observability requires initializing certain things and classes, which makes the task within the try-with-resources block take longer. However, when observability is disabled, I did not observe many initializations in the test cases at lines 233 and 236, so I refactored the code to use a traditional try-catch block instead.

@ejona86
Copy link
Member

ejona86 commented Dec 26, 2024

You just don't close? No, we need to clean up and we want to test cleanup. Without close() we will leak resources and probably threads, and we don't want those running during other tests.

@harshagoo94
Copy link
Author

You just don't close? No, we need to clean up and we want to test cleanup. Without close() we will leak resources and probably threads, and we don't want those running during other tests.

@ejona86,

I’m working on this and plan to implement a close() method with a configurable sleep time. After the test finishes, the close() method will be called with a shorter sleep duration to speed up the cleanup process.

@ejona86
Copy link
Member

ejona86 commented Dec 27, 2024

That sounds fine; just make the new method package-private.

@harshagoo94
Copy link
Author

@shivaspeaks ,

As per the suggestions above, I have pushed the latest changes, which include the addition of a new close method with sleep time. After executing the test case, I found that the execution time is now under 5 seconds.

Could you please review the changes.

@@ -146,6 +146,21 @@ public void close() {
}
}

public void closeWithSleepTime(long sleepTime) {
Copy link
Contributor

Choose a reason for hiding this comment

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

please add the missing doc comments for this method.

Copy link
Author

Choose a reason for hiding this comment

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

Resolved

gcpObservability.closeWithSleepTime(sleepTime);
verify(sink).close();
}

Copy link
Contributor

Choose a reason for hiding this comment

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

remove this extra line

Copy link
Author

Choose a reason for hiding this comment

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

Resolved

public void closeWithSleepTime() throws Exception {
long sleepTime = 1000L;
Sink sink = mock(Sink.class);
ObservabilityConfig config = mock(ObservabilityConfig.class);
Copy link
Contributor

Choose a reason for hiding this comment

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

change variable config to observabilityConfig

Copy link
Author

Choose a reason for hiding this comment

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

Resolved

….enableObservability test case - fixed review comments.
….enableObservability test case - fixed review comments.
Copy link
Contributor

@vinodhabib vinodhabib left a comment

Choose a reason for hiding this comment

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

Changes LGTM and Lets wait for Review from @ejona86 @shivaspeaks

@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Jan 3, 2025
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Jan 3, 2025
*
* @param sleepTime sleepTime
*/
public void closeWithSleepTime(long sleepTime) {
Copy link
Member

Choose a reason for hiding this comment

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

Don't make this public. We just want it for testing.

*/
public void closeWithSleepTime(long sleepTime) {
synchronized (GcpObservability.class) {
sink.close();
Copy link
Member

Choose a reason for hiding this comment

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

Add the missing instance == null check, and then have the old method call this new method with a hard-coded delay.

*
* @param sleepTime sleepTime
*/
public void closeWithSleepTime(long sleepTime) {
Copy link
Member

Choose a reason for hiding this comment

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

sleepTime has no unit attached. You should either include the unit in the same, like sleepTimeMillis (this is more common in fields) or pass a TimeUnit as another parameter (this is more common in APIs). So here I suggest passing in a TimeUnit.

@@ -208,6 +208,7 @@ public void run() {
assertThat(list.get(2)).isInstanceOf(ConditionalClientInterceptor.class);
assertThat(configurator.serverInterceptors).hasSize(1);
assertThat(configurator.tracerFactories).hasSize(2);
gcpObservability.closeWithSleepTime(3000);
} catch (Exception e) {
Copy link
Member

Choose a reason for hiding this comment

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

When the try block is exited, it calls close() again. We should be seeing a IllegalStateException exception. If the tests are passing, that needs to be looked in to.


// Test to verify the closeWithSleepTime method along with sleep time explicitly.
@Test
public void closeWithSleepTime() throws Exception {
Copy link
Member

Choose a reason for hiding this comment

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

This seems identical to StaticTestingClassEnableObservability, except for the verify(sink).close(). That would be good to move to the other test and then we delete this one.

@ejona86 ejona86 changed the title gcp-obsrevability : Fixed the slowness issue for GcpObservabilityTest.enableObservability test case. gcp-observability: Fixed slowness for GcpObservabilityTest.enableObservability test case Jan 3, 2025
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.

GcpObservabilityTest.enableObservability is way slow
5 participants