-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Performance Framework Investigation #32020
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
Changes from all commits
40ebb70
4ab0f46
4250b1b
5da0fa1
61e5030
eace59c
d925279
5bb0c06
577bc62
ad1b4a3
7e82502
ab7a11b
9e2b8b1
99ca3d4
56640c4
432246e
aa1d94b
ddfbdaa
8a17289
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,7 +7,6 @@ | |
| import com.azure.storage.blob.perf.core.ContainerTest; | ||
| import reactor.core.publisher.Flux; | ||
| import reactor.core.publisher.Mono; | ||
| import reactor.core.scheduler.Scheduler; | ||
| import reactor.core.scheduler.Schedulers; | ||
|
|
||
| import java.util.UUID; | ||
|
|
@@ -25,12 +24,15 @@ public Mono<Void> globalSetupAsync() { | |
| // drastically less CPU usage and throughput, there is ongoing discussions with Reactor Netty on what causes | ||
| // this edge case, whether we had a design flaw in the performance tests, or if there is a configuration change | ||
| // needed in Reactor Netty. | ||
| int parallel = options.getParallel(); | ||
| return super.globalSetupAsync().then( | ||
| Flux.range(0, options.getCount()) | ||
| .parallel(options.getParallel()) | ||
| .runOn(Schedulers.boundedElastic()) | ||
| .parallel(parallel) | ||
| .runOn(Schedulers.parallel()) | ||
| .flatMap(iteration -> blobContainerAsyncClient.getBlobAsyncClient("getblobstest-" + UUID.randomUUID()) | ||
| .upload(Flux.empty(), null), false, Math.min(options.getParallel(), 1000 / options.getParallel()), 1) | ||
| .getBlockBlobAsyncClient() | ||
| .upload(Flux.empty(), 0L), false, parallel, 1) | ||
| .sequential() | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the purpose of
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. All examples of ParallelFlux used in Reactor's samples used |
||
| .then()); | ||
| } | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3,21 +3,38 @@ | |
|
|
||
| package com.azure.storage.blob.perf.core; | ||
|
|
||
| import com.azure.storage.blob.models.ParallelTransferOptions; | ||
| import com.azure.storage.blob.perf.BlobPerfStressOptions; | ||
| import reactor.core.publisher.Mono; | ||
|
|
||
| import static com.azure.perf.test.core.TestDataCreationHelper.createRandomByteBufferFlux; | ||
|
|
||
| public abstract class AbstractDownloadTest <TOptions extends BlobPerfStressOptions> extends BlobTestBase<TOptions> { | ||
| private static final long GB = 1024 * 1024 * 1024; | ||
|
|
||
| public AbstractDownloadTest(TOptions options) { | ||
| super(options, BLOB_NAME_PREFIX); | ||
| } | ||
|
|
||
| // Upload one blob for the whole test run. All tests can download the same blob | ||
| public Mono<Void> globalSetupAsync() { | ||
| /* | ||
| * Uploading the blob is set to use a "single shot" and block size of 1GB to have the blob upload over a single | ||
| * connection. There was an investigation into an issue in the performance tests where all connections were | ||
| * being handled by a single IO thread, the root cause was found to be that when 1GB download set up resources | ||
| * here the sequential uploading of 4MB blocks resulted in Reactor Netty using the same thread to manage all | ||
| * upload connections (1GB / 4MB = 256). The test only used 8 threads to perform parallel 1GB download and since | ||
| * 8 connections already existed they were reused and managed by that single IO thread. So, changing upload to | ||
| * be done with a single connection fixes that, where when 8 threads begin performing download at the same time | ||
| * Reactor Netty has to even spread those requests over the available IO threads instead of being pinned to | ||
| * the one IO thread. | ||
| * | ||
| * In the future there will be work to separate the HttpClients used to perform resource preparation and running | ||
| * the performance test. As part of that work this can be reverted to using the default ParallelTransferOptions. | ||
| */ | ||
| return super.globalSetupAsync() | ||
| .then(blobAsyncClient.upload(createRandomByteBufferFlux(options.getSize()), null)) | ||
| .then(blobAsyncClient.upload(createRandomByteBufferFlux(options.getSize()), new ParallelTransferOptions() | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you add a comment explaining why we are overriding the default upload size and block size? Is 1GB the max, or could we set it even higher (in case we want to start testing blobs > 1GB)?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Left a comment explaining this |
||
| .setMaxSingleUploadSizeLong(GB).setBlockSizeLong(GB))) | ||
| .then(); | ||
| } | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.