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

[Service Bus] StressTests scenarios #11546

Merged

Conversation

HarshaNalluru
Copy link
Member

@HarshaNalluru HarshaNalluru commented Sep 29, 2020

"stress-tests-track-2" folder is an independent npm project with a package.json. Currently, testing preview.6 version of the SDK.
The following is a brief introduction to the contents.

stressTestsBase

  • Creates a new service-bus queue
  • Provides methods that would call into each of the main methods of the service bus API
  • Tracks the info related to successes, failures and errors corresponding to the operations
  • Snapshots at every 5 seconds, logs into a file

scenario{...}.ts

  • Instantiates StressTestsBase, and uses the methods provided by the class and tailors the scenario
  • Each of the scenarios can be executed without any setup, just by running through ts-node
  • Takes command-line arguments which allows granular control over the scenario
  • Example - ts-node scenario{...}.ts --delayBetweenSendsInMs=100

setupAndGuide.md

  • As the name says, it has the setup and the commands to run to test a specific scenario

@ghost ghost added the Service Bus label Sep 29, 2020
@HarshaNalluru HarshaNalluru changed the title [Service Bus] StressTests framework and starter scenarios [Service Bus] StressTests starter scenarios Sep 29, 2020
@HarshaNalluru HarshaNalluru changed the title [Service Bus] StressTests starter scenarios [Service Bus] StressTests scenarios Sep 29, 2020
Copy link
Member

@richardpark-msft richardpark-msft left a comment

Choose a reason for hiding this comment

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

Looking like a great start to me.

I'm wondering if you can lean on any of the work we've got for our normal live tests (like creating/recreating entities, etc..)

@richardpark-msft
Copy link
Member

Also want to mention that you've got a lot of TODOs about making the limits configurable, which is great. I would suggest we get that in place sooner rather than later or else we'll end up baking them in unintentionally and with these kinds of tests you want to be clear about what your measurements/intervals/timings are.

@HarshaNalluru
Copy link
Member Author

I'm wondering if you can lean on any of the work we've got for our normal live tests (like creating/recreating entities, etc..)

Good idea.. I'll re-use wherever I can.

"author": "",
"license": "ISC",
"dependencies": {
"@azure/service-bus": "^7.0.0-preview.6",
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
"@azure/service-bus": "^7.0.0-preview.6",
"@azure/service-bus": "^7.0.0-preview.7",

Copy link
Member Author

Choose a reason for hiding this comment

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

Currently, the code is written based on preview.6, I'll update both the code and the version to incorporate the changes that we recently did to sessions.

Copy link
Member Author

Choose a reason for hiding this comment

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

Forgot to update that I've updated this! :P

Comment on lines 68 to 76
let receiver: ServiceBusReceiver<ServiceBusReceivedMessage>;

if (receiveMode === "receiveAndDelete") {
receiver = sbClient.createReceiver(stressBase.queueName, {
receiveMode: "receiveAndDelete"
});
} else {
receiver = sbClient.createReceiver(stressBase.queueName);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not use the receiveMode directly?

Suggested change
let receiver: ServiceBusReceiver<ServiceBusReceivedMessage>;
if (receiveMode === "receiveAndDelete") {
receiver = sbClient.createReceiver(stressBase.queueName, {
receiveMode: "receiveAndDelete"
});
} else {
receiver = sbClient.createReceiver(stressBase.queueName);
}
const receiver = sbClient.createReceiver(stressBase.queueName, {
receiveMode: "receiveAndDelete"
});

Copy link
Member Author

@HarshaNalluru HarshaNalluru Oct 9, 2020

Choose a reason for hiding this comment

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

That's a typescript limitation with the string literal union types - example to try out.

In a gist, it tries to match the union type with the string literal type from each of the overloads in the function definition, and none of them match individually.

);
elapsedTime = new Date().valueOf() - startedAt.valueOf();
messages.map((msg) =>
stressBase.renewMessageLockUntil(
Copy link
Contributor

Choose a reason for hiding this comment

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

It is not clear to me what our expectation here is...
The renewMessageLockUntil will keep renewing the lock... what are we looking for? That no error occurs?
Where will the error surface?

And when does the program end? We are awaiting on receiveMessages() but not really for the renewMessageLockUntil to finish?

Copy link
Member Author

Choose a reason for hiding this comment

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

The time duration for renewMessageLockUntil is less than the testDuration always, and hence would end before, and lock renewals are being done through setTimeouts.

The intention behind the test is to have many messages for which we'd be renewing the locks, note down the errors if any, observe the limits.. as in number of messages can we handle, etc.

while (elapsedTime < testDurationInMs) {
let receiver;
try {
receiver = await sbClient.createSessionReceiver(stressBase.queueName, {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why create a new receiver in each iteration of the loop?

Copy link
Member Author

Choose a reason for hiding this comment

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

The intention behind this test to keep renewing the locks for multiple sessions and observe any unexpected behaviour with maintaining a huge number of sessions at the same time.

@ramya-rao-a ramya-rao-a merged commit b6cb91d into Azure:master Oct 30, 2020
ghost pushed a commit that referenced this pull request Nov 11, 2020
### Original issue - #11108
Follow-up of the stress tests PR #11546, here are the changes
- Uses the latest preview.8 version of the service-bus SDK
- Fixes the boolean options being passed as command-line args
- Multiple sessions support in the renew session lock test
- Adds (some)new options that can be passed as command-line args to the tests
- And maybe minor edits
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants