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

Add perf testing for singleton client usage #4

Conversation

samvaity
Copy link

@samvaity samvaity commented Dec 6, 2021

UploadFile Test (Singleton client)

image

UploadFile Test

image

BlobServiceClient storageClient = blobServiceClientBuilder.buildClient();

BlobContainerClient blobContainerClient = storageClient.createBlobContainer("perfupload" + UUID.randomUUID());
BlobProperties blobProperties = blobContainerClient.getBlobClient(blobName).getProperties();
Copy link
Author

Choose a reason for hiding this comment

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

@alzimmermsft This gives me a 404 for BlobNotFound for this test case but not the UploadFile . Is getProperties api selectively available?

Copy link
Owner

Choose a reason for hiding this comment

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

So, upload from file will create a blob but I'm guessing it didn't exist previously, this performance test will need to create the blob in setup first

Comment on lines 40 to 41
assert blobProperties.getCreationTime() != null;
assert blobProperties.getExpiresOn() != null;
Copy link
Owner

Choose a reason for hiding this comment

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

nit: no need to do validation logic once we're happy with the validity of the perf test

Comment on lines 33 to 39
String blobName = "perfblobtest-" + UUID.randomUUID();

BlobServiceClient storageClient = blobServiceClientBuilder.buildClient();

BlobContainerClient blobContainerClient = storageClient.createBlobContainer("perfupload" + UUID.randomUUID());
BlobClient blobClient = blobContainerClient.getBlobClient(blobName);
blobClient.uploadFromFile(filePath, true);
Copy link
Owner

Choose a reason for hiding this comment

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

For both tests, and the sync and async variants, we'll want to either add a configuration flag to share the singleton HttpClient or to use a new one on each call. Or does it always share the HttpClient given which branch this PR is targeting?

Copy link
Author

@samvaity samvaity Dec 7, 2021

Choose a reason for hiding this comment

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

yes, Used different dependency versions, a locally compiled one vs already deployed.

we'll want to either add a configuration flag to share the singleton HttpClient

Idk, if we support using a configuration flag to specify to use or not use a shared http client.

Copy link
Owner

@alzimmermsft alzimmermsft left a comment

Choose a reason for hiding this comment

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

Could we get performance numbers for getting properties when using a shared and non-shared HttpClient. This is a lighter service, and network, operation that'll better show the performance implications of the change.

Comment on lines +32 to +36
<dependency>
<groupId>com.azure</groupId>
<artifactId>azure-storage-blob</artifactId>
<version>12.13.0-beta.1</version> <!-- {x-version-update;com.azure:azure-storage-blob;dependency} -->
</dependency>
Copy link
Owner

Choose a reason for hiding this comment

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

I'd also add the current version of azure-core as a dependency to this. Reason being that it'll override the dependency in any downstream libraries being used in testing to provide the following:

  • Changes to Core will be performance tested.
  • Regressions in Core will be more likely to be found.
  • It will test the latest Core which performance tests should be doing.

@@ -83,7 +83,7 @@
<dependency>
<groupId>com.azure</groupId>
<artifactId>azure-core-http-netty</artifactId>
<version>1.11.4</version> <!-- {x-version-update;com.azure:azure-core-http-netty;dependency} -->
<version>1.12.0-beta.1</version> <!-- {x-version-update;unreleased_com.azure:azure-core-http-netty;dependency} -->
Copy link
Owner

Choose a reason for hiding this comment

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

I would revert this in favor of the performance test overriding the version of Netty being used.

Comment on lines +35 to +49
if (useSharedClient) {
BlobServiceClient blobServiceClient = blobServiceClientBuilder.buildClient();
performGetProperties(blobServiceClient);
} else {
// use a customized http client
HttpClientOptions clientOptions = new HttpClientOptions().setMaximumConnectionPoolSize(50);
HttpClient client1 = new NettyAsyncHttpClientProvider().createInstance(clientOptions);

BlobServiceClient blobServiceClient = blobServiceClientBuilder
.httpClient(client1)
.buildClient();

performGetProperties(blobServiceClient);
}
}
Copy link
Owner

Choose a reason for hiding this comment

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

So, given the way Storage works both of these will end up sharing the HttpClient. Storage passes the HttpPipeline of a parent resource (service client -> container client, container client -> blob client) to the child resource. It may be better to pass a Supplier<BlobContainerClient>, or Function<String, BlobContainerClient>, where the one for a shared client is passing the pre-built client and the one for a non-shared client goes through a new builder.

@samvaity samvaity closed this Sep 14, 2022
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.

2 participants