-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[Perf Framework] BatchPerfTest & Service Bus Receive Batch perf test #18811
[Perf Framework] BatchPerfTest & Service Bus Receive Batch perf test #18811
Conversation
Co-authored-by: Daniel Rodríguez <sadasant@users.noreply.github.com>
Co-authored-by: Daniel Rodríguez <sadasant@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approve changes to perf framework. Requested one change to the receiveBatch
test.
"message-body-size-in-bytes": number; | ||
} | ||
|
||
export class BatchReceiveTest extends ServiceBusTest<ReceiverOptions> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think BatchReceiveTest
should extend BatchPerfTest
rather than PerfTest
(which ServiceBusTest
extends).
While it is possible in JS to extend PerfTest
and then override the runBatch()
method, it should not be recommended, and this is not possible in other languages like .NET, where PerfTest
seals the runBatch()
method to prevent further overriding:
TypeScript does not support "sealed/final" methods, so I'm not sure if there is any reasonable way to prevent overriding PerfTest.runBatch()
, but we should at least discourage it and make sure we don't do it in our examples.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I'd either create two base classes like ServiceBusTest extends PerfTest
and ServiceBusBatchTest extends BatchPerfTest
, or just use ServiceBusTest extends BatchPerfTest
, and have all tests override runBatch()
(and return 1
if only performing a single operation).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ServiceBusTest extends BatchPerfTest, and have all tests override runBatch() (and return 1 if only performing a single operation)
My intention was to reuse the setup hence updated PerfTest to have both.
I like your suggested approach, will update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- We don't have "sealed"
- We could try decorators, but they are experimental yet and subject to change
- We have "abstract", "public", "private", "protected" and "override" keywords
- We use "abstract" as intended
- We can't use "private"/"protected" for run/runBatch
- Override is not relevant
- Looks like we need to make run and runBatch public
- However, I updated the base SBTestBase to extend the BatchPerfTest instead.
…thub.com/HarshaNalluru/azure-sdk-for-js into harshan/issue/18471-event-perf-framework
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I’m excited about this project.
… harshan/issue/18471-event-perf-framework
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good :)
public async runBatch(): Promise<number> { | ||
const messages = await this.receiver.receiveMessages( | ||
this.parsedOptions["max-message-count"].value, | ||
{ maxWaitTimeInMs: 500 } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could this be another parameter to the test?
export abstract class BatchPerfTest<TOptions = Record<string, unknown>> extends PerfTestBase< | ||
TOptions | ||
> { | ||
private readonly testProxy!: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could testProxy
be optional instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same goes for the other two members.
* | ||
* Note: httpClient must be part of the options bag, it is required for the perf framework to update the underlying client properly | ||
*/ | ||
public configureClientOptionsCoreV1<T>(options: T & { httpClient?: HttpClient }): T { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the function type signature suggests it removes httpClient
from the input but it does not. I think the following can be slightly more descriptive:
public configureClientOptionsCoreV1<T extends { httpClient?: HttpClient }>(options: T): T
} | ||
|
||
/** | ||
* Runs the test in scope repeatedly, without waiting for any promises to finish, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
waiting for any promises to finish
I am confused by this comment because the only promise in scope, this.runBatch(abortController.signal)
, is being awaited.
…vice Bus Track 1 (#19790) **Packages impacted by this PR:** - `@azure-tests/perf-service-bus-track-1` **Issues associated with this PR:** - #18982 **Describe the problem that is addressed by this PR:** Add a test for receiveBatch using the track 1 service bus SDK in line with what we already have for the track 2 SDK **Provide a list of related PRs** _(if any)_ - #18811
[App Configuration] Promote 2022-05-01 stable version (Azure#18811) * Add 2022-05-01 folder based on 2021-10-01-preview * Update 2022-05-01 folder * Fix readme issue
Fixes #18329
Changes
PerfTestBase
andBatchPerfTest
.PerfTestBase
abstract class with the skeleton of the perf tests.BatchPerfTest
extendsPerfTestBase
,BatchPerfTest
enables writing perf tests with more flexibility where the number of operations are dynamic for the method/call being tested.PerfTest
now extendsBatchPerfTest
, a single call in the "run" method for the method being tested counts as one operation - has no breaking changes now and is supposed to work as it did before.ReceiveBatch
perf test for service-bus track 2.ParsedPerfOptions<TOptions = Record<string, unknown>>
for the parsed options, which doesn't require to add/bypass the "value" existence check.this.parsedOptions.optionName.value!
->this.parsedOptions.optionName.value
in the perf tests.TODO
perf-js-libs
rhea and others to follow the new perf tests for better comparison and delete the olderperf-js-libs
folder [Service Bus] [Perf Tests] Migrateperf-js-libs
rhea and others to follow the new perf tests #18983 loggedparsePerfOption
method internally with thethis.options
anddefaultPerfOptions
arguments. This is fine because they both don't have an overlap. However, we don't make sure there is no overlap during the validation. Overlapping props can lead to unexpected behaviors. Make sure the validation method or the type validation throw/complain about re-declaring in options bag with the names from default options.