AppServicePlanListStep - performance improvement

[ccastrotrejo]

We use the AppServicePlanListStep on the logic apps vscode extension when trying to create a new resource in azure.
However we have noticed that the AppServicePlanListStep take a long time to load the quickpicks. There are some users that it takes more than 2 minutes.

I did a quick time measurement on our side and the const epPlan: AppServicePlan | undefined = await tryGetAppServicePlan(client, nonNullProp(plan, 'resourceGroup'), nonNullProp(plan, 'name')); its the one function that takes a long time to be executed (I understand it does make API calls).

Is there something we can do to improve the performance on getting the quick picks?

[bwateratmsft]

@nturinski we should look at this one. I noticed it's doing a fetch for every single app service plan, just to check whether it's Linux...that's not great. The comments mention that this is because of Elastic Premium plans not returning all the relevant data in the list request, but we need to do better than this.

[nturinski]

I noticed it's doing a fetch for every single app service plan

Looking into it, we only do it for EP and WS plans. We don't personally ever create these plans for users (I think you can select it in advanced create) but I'm assuming that they are getting used primarily by Logic Apps based on this issue.

I'm all for improving the perf, but I don't think it impacts most of our Functions/App Service users.

I'm not really sure why we're doing this either:

if (isNewSiteLinux === isPlanLinux) {
                if (location && !LocationListStep.locationMatchesName(location, plan.location)) {
                    hasFilteredLocations = true;
                } else {
                    picks.push({
                        id: plan.id,
                        label: nonNullProp(plan, 'name'),
                        description: plan.sku?.name,
                        data: plan
                    });
                }
            }

Seems like we only filter Linux plans based on location? 😕

EDIT: We filter location based on Windows or Linux. The reason being we select the OS first and only show ASPs that are that OS. The reason this filter was added is because location was moved to being before ASP, so we wanted to filter plans based on location.

[nturinski]

To improve perf, we came up with this solution:

Start retrieving the app service plans (including the tryGetAppServicePlan to get the Linux OS info) on the first step of the wizard and have it run in the background while the user is filling out the rest of the wizard.

Then we just do all the filtering based on their prompts when they actually get to the AppServicePlanListStep

[bwateratmsft]

I mentioned in #2158, but we should also add some parallelism to the web requests. Additionally, I have seen some endpoints where you must explicitly ask, in the request, for certain things to be "expanded" in order for them to be filled out when listing. As an example, see here. Maybe something like that can be used here?

[andrew-eldridge]

I don't think the current solution will improve performance much in our case where there are sometimes hundreds of ASPs and the fetch for each one is awaited. Running in the background during previous steps makes a negligible difference, we really need the parallel requests here

[bwateratmsft]

@nturinski I tried out some list operations today using the AZ CLI, and I think that reserved is now being set all the time, at least in the API version that AZ is using (api-version=2024-11-01).

I created a handful of plans, observe the output from listing:

az appservice plan list --resource-group bwater --query "sort_by([].{name:name, reserved:reserved, sku:sku.name}, &name)" --output table

Name                  Reserved    Sku
--------------------  ----------  -----
bwater-plan-ep-linux  True        EP1
bwater-plan-ep-win    False       EP1
bwater-plan-s1-linux  True        S1
bwater-plan-s1-win    False       S1
bwater-plan-ws-linux  True        WS1
bwater-plan-ws-win    False       WS1

There is also a detailed option that can be passed in to the list operation, but it may not be needed anyway: https://learn.microsoft.com/en-us/rest/api/appservice/app-service-plans/list?view=rest-appservice-2024-11-01&tabs=HTTP#uri-parameters

It looks like the current logic was originally authored back in 2019 or 2020, depending how you count. Whatever issue existed then doesn't seem to exist anymore.

[nturinski]

Think I should just go ahead and merge #2203 then?

[bwateratmsft]

@nturinski No I think we just use plans from

vscode-azuretools/appservice/src/createAppService/AppServicePlanListStep.ts

Line 90 in 2a141e9

let plans: AppServicePlan[] = await AppServicePlanListStep.getPlans(context);

and check sku/reserved. No need for any extra queries. We should make sure the current SDK version uses an API version that consistently returns true for reserved on Linux plans.