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?