What is the most throughput-optimized way to process multiple Azure Service Bus queues in an ASP.NET core background service?

Explicit questions in a bulleted list at the end

I am creating a new ASP.NET solution that will be deployed as a microservice to handle processing and storing audits for transactions in our system. The data that needs to be audited is being placed on an Azure Service Bus queue and I would like the service I’m developing to continuously process those requests as they come in. To achieve this I am creating a BackgroundService that, when started, will run continuously and process messages that enter the queue. I started with a simple one queue case and the code looked like the below.

Program.cs (entrypoint/startup code)

using System.Data.SqlClient;
using Microsoft.AspNetCore.Server.Kestrel.Core;
using Microsoft.Extensions.Azure;

var builder = WebApplication.CreateBuilder(args);

// Various builder initializations that are not relevant for this post

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddServiceBusClient("<AzureServiceBusConnectionString>").WithName("queueName");
});
//QueueProcessorService is the custom background service I created
builder.Services.AddHostedService<QueueProcessorService>();

// We have a custom extension for the web app builder that builds/runs
builder.CustomRunWebApi();

QueueProcessorService

public class QueueProcessorService : BackgroundService
    {
        private readonly List<ServiceBusProcessor> _queueProcessors = new();
        public QueueProcessorService(IAzureClientFactory<ServiceBusClient> serviceBusClientFactory)
        {
            // I have tried various options for this and it performs about the same everytime
            var processorOptions = new ServiceBusProcessorOptions
            {
                MaxConcurrentCalls = 20,
                PrefetchCount = 50,
            };
            var client = serviceBusClientFactory.CreateClient("queue1");
            var processor = client.CreateProcessor("queue1", processorOptions);
            processor.ProcessMessageAsync += MessageHandler;
            processor.ProcessErrorAsync += ErrorHandler;
            processor.StartProcessingAsync();
            _queueProcessors.Add(processor);
        }
        protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            // Through testing and messing around I need to yield here so the web api builds and runs as expected. 
            await Task.Delay(1, stoppingToken);
            stoppingToken.Register(async () =>
            {
                foreach (var processor in _queueProcessors)
                {
                    await processor.DisposeAsync();
                }
            });
            while (!stoppingToken.IsCancellationRequested)
            {
                continue;
            }
            return;
        }


        private static async Task MessageHandler(ProcessMessageEventArgs args)
        {
            Console.WriteLine($"Starting processing message for queue {args.EntityPath}");
            try
            {
                var body = args.Message.Body.ToString();
                var claimJson = JObject.Parse(body);
                // Process JSON
                // Eventually this will have business logic but for testing it's doing nothing
                Console.WriteLine($"Completed processing message for queue {args.EntityPath}");
            }
            catch (Exception e)
            {
                Console.WriteLine(e);
            }
        }

        private static Task ErrorHandler(ProcessErrorEventArgs args)
        {
            Console.WriteLine(args.Exception.ToString());
            return Task.CompletedTask;
        }
    }

I ran some simple test cases on the above and it worked fine. I then wanted to figure out how to appropriately handle the scale of our transactions. We have fewer than 70 customers each that has their own isolated system that processes transactions. I would like to develop this to be multi-tenant so I would like to use a shared Service Bus. For logical separation I was leaning towards one queue per customer and simply instantiating one processor per queue. Here’s how I tried to implement the one queue per customer in my code.

I made this change in Program.cs to add multiple clients. Note the connection string is the same, is this actually creating multiple instances? Based on this article I am trying to create one client per queue. Additionally that article mentions to use multiple factories, but I don’t really get the benefit to creating a separate factory versus a separate instance.

builder.Services.AddAzureClients(clientBuilder =>
{
    // QueueNames is just a list of queue names
    foreach (var queueName in QueueConfiguration.QueueNames)
    {
        clientBuilder.AddServiceBusClient("<ConnectionString>").WithName(queueName);
    }
});

I made the following changes to the QueueProcessorService constructor

public QueueProcessorService(IAzureClientFactory<ServiceBusClient> serviceBusClientFactory)
        {
            foreach (var queueName in QueueConfiguration.QueueNames)
            {
                var processorOptions = new ServiceBusProcessorOptions
                {
                    MaxConcurrentCalls = 20,
                    PrefetchCount = 10,
                };
                var client = serviceBusClientFactory.CreateClient(queueName);
                var processor = client.CreateProcessor(queueName, processorOptions);
                processor.ProcessMessageAsync += MessageHandler;
                processor.ProcessErrorAsync += ErrorHandler;
                processor.StartProcessingAsync();
                _queueProcessors.Add(processor);
            }
        }

I created a simple script which runs for a configurable amount of seconds and just sends messages to random queues within QueueNames and it takes a significant amount of time after that script finishes to fully empty all the queues. For reference, I was testing with 50 queues and this is a Standard tier service bus. We will use a Premium in production, but I wanted to ensure that my code/structure is sound and with what I am seeing I do not think that it is sound, hence this post.

I have a few questions after this experiment:

• Am I simply trying to process too many queues in the background service? I know I could probably handle this all in one queue, but I like the logical separation and it’s far below the limit provided by Azure Service Bus so I would have thought that would not be an issue
• Is there a more appropriate way to configure and initialize the N queue processors on startup? Based on the Learn article I linked previously I was trying to create one client per queue. Additionally I followed this post for my approach. However, I know that post the setup is different in that each client has a different namespace/connection-string.
• Is this performance issue likely due to using a standard tier Azure Service Bus? I doubt it. For reference, the script I was using was not an exceptionally high throughput. It was anywhere from 440 to 600 messages in 30 seconds. When it was done processing there were anywhere from 130-200 messages spread across the queues and it took about a minute to ninety seconds to process the rest of them.
• I have tried tweaking some of the ServiceBusProcessorOptions but it doesn’t seem to magically fix the issue. I followed the general advice of the article I linked earlier in my post, but is there some other advice or input that could help me here?

My thought is that either I am not getting the right client/queue granularity during DI and/or my configuration is off. Thanks for any help, and if I can clarify anything or more details are needed please let me know.