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

[Perf] Refactor tests.yml into one file per package per language #5083

Merged
43 commits merged into from
Feb 10, 2023

Conversation

mikeharder
Copy link
Member

@mikeharder mikeharder commented Jan 7, 2023

TODO

  • Improve LanguageVersion
    • How are defaults selected
    • Report requested and actual versions, verify versions match

Testing

  • Manually run storage tests in all languages
  • Run pipelines in all languages

@azure-sdk
Copy link
Collaborator

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

@Azure Azure deleted a comment from azure-sdk Feb 9, 2023
@Azure Azure deleted a comment from azure-sdk Feb 9, 2023
@Azure Azure deleted a comment from azure-sdk Feb 9, 2023
@Azure Azure deleted a comment from azure-sdk Feb 9, 2023
@mikeharder
Copy link
Member Author

@heaths, @jsquire, @christothes:

This set of PRs is a huge improvement over the status quo, where the metadata for all tests across all languages lives in a single file in the tools repo:

https://github.com/Azure/azure-sdk-tools/blob/de045afa1901dd6b6a3d43a01bec1f3d9fb4f4f0/tools/perf-automation/Azure.Sdk.Tools.PerfAutomation/tests.yml

These PRs move this metadata to the language+service directories, which allows updating the perf tests in a single PR to the language repo, rather than also requiring a PR to the tools repo. It also allows languages to additional tests or arguments, beyond the standard set we keep consistent across all languages.

The perf v-team has been waiting months for this refactoring. So I would like to land these PRs with the current design, and we can discuss further improvements after these are merged.

The perf-tests.yml file contains all the metadata needed for the perf pipeline (using the PerfAutomation app) to know which tests to run with which arguments. Specifically:

  • The language-agnostic name for the service (e.g. storage-blob)
  • The language-specific project containing the perf tests for this service (e.g. sdk/storage/Azure.Storage.Blobs/perf/Azure.Storage.Blobs.Perf/Azure.Storage.Blobs.Perf.csproj)
  • The sets of package versions to run the perf tests against (e.g. "latest GA" and "sources")
  • The language-agnostic name for each test (e.g. download)
  • The language-specific class representing this test (e.g. DownloadBlob)
  • The arguments to pass to each test (e.g. list of blob sizes)

It may be possible to move some or most of this information into the perf test source code itself. For example, in .NET, the list of arguments could be expressed as a set of custom attributes on the perf test class. And I can see some advantages to this.

However, one of the principles we have been using for our performance infrastructure, is to keep the code specific to each language as simple as possible, and move the complexity into the language-agnostic PerfAutomation app. Anything language-specific needs to be implemented 5 times (.NET, Java, JS, Python, C++), and kept consistent across the languages. So we have tried to keep the language-specific perf frameworks as simple and lightweight as possible, and encoding this metadata in perf-tests.yml rather than in the language-specific perf source code allows this to happen.

If .NET would like to prototype an end-to-end solution that moves this metatadata from perf-tests.yml into the perf source code, I am happy to review. The next question would be if all the other languages want to implement something similar, or continue using perf-tests.yml (so .NET would be an outlier).

My personal opinion is the current perf-tests.yml is the best solution overall, since it minimizes the amount of work we need to do in each language. But if the language teams feel differently, and are willing to fund the language-specific work to change this, I am open to the idea. However, I will also say if the language teams want to spend more time on perf, I think there are higher-value activities than moving this metadata to a different place.

@jsquire
Copy link
Member

jsquire commented Feb 9, 2023

I think the main concern here for me is the number of things that a performance test author has to remember to update and the disconnect for understanding why the new test that you wrote wasn't executed. I'd prefer to see us remove the need to have metadata present to run the test (run them all by default) and, instead, let the dashboard show results that don't align if it's not set.

That way, it's clear that a test is running and that "something" needs to happen for it to be grouped with its peers from other languages which can help drive the necessary follow-up conversations to discover what steps are needed.

@azure-sdk
Copy link
Collaborator

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

@g2vinay
Copy link
Member

g2vinay commented Feb 9, 2023

The feedback provided from .NET folks above around the design is helpful and can be factored in next iteration of perf infra.

@azure-sdk
Copy link
Collaborator

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

@heaths
Copy link
Member

heaths commented Feb 9, 2023

I've set up a meeting with @jsquire and @pallavit to discuss next steps, if any. I'm thinking cross-language and appreciate @mikeharder's design ideas we discussed offline. I think there's relatively low-cost ways to achieve the same thing without complicating the onboarding process for new contributors to maintain yet another document, since they already have to write code to add tests.

The value of this PR over the existing process is not in question: clearly this is a vast improvement. But the less maintenance hassles in the long run the better. Ideally, I think the runners can effectively multiplex the different permutations into separate processes (this is how .NET test runners generally work, and even multi-targeting builds that we already use for testing). That may be harder on some languages than others, granted.

But I also empathize with Mike that this is something we do relatively infrequently. Still, if we make it a docs issue...well, I've already seen more than enough cases where we have docs - somewhere - and people still go outside those norms like we've seen recently with tests/samples/snippets for .NET. More automation and less manual effort tends to help.

To clarify, though, I see no reason to hold up this current effort. It's clearly better than what exists now with a disconnected, centralized repo.

@ghost
Copy link

ghost commented Feb 10, 2023

Hello @azure-sdk!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit d555cb2 into Azure:main Feb 10, 2023
@mikeharder mikeharder deleted the perf-refactoring branch February 10, 2023 05:15
HarshaNalluru pushed a commit to HarshaNalluru/azure-sdk-for-js that referenced this pull request Feb 10, 2023
Sync eng/common directory with azure-sdk-tools for PR
Azure/azure-sdk-tools#5083 See [eng/common
workflow](https://github.com/Azure/azure-sdk-tools/blob/main/eng/common/README.md#workflow)

---------

Co-authored-by: Mike Harder <mharder@microsoft.com>
This pull request was closed.
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.

6 participants