Eu escrevi uma API usando aspap webapi e a implantei no azure como Appservice. O nome do meu controlador é TestController e Meu método de ação é algo como abaixo.

    [Route("Test/Get")]
    public string Get()
    {
        Thread.Sleep(10000);
        return "value";
    }

Portanto, para cada solicitação, espere 10 segundos antes de retornar a string "value". Também escrevi outro ponto de extremidade para ver o número de threads no conjunto de threads trabalhando para executar solicitações. Essa ação é algo como abaixo.

    [Route("Test/ThreadInfo")]
    public ThreadPoolInfo Get()
    {
        int availableWorker, availableIO;
        int maxWorker, maxIO;

        ThreadPool.GetAvailableThreads(out availableWorker, out availableIO);
        ThreadPool.GetMaxThreads(out maxWorker, out maxIO);

        return new ThreadPoolInfo
        {
            AvailableWorkerThreads = availableWorker,
            MaxWorkerThreads = maxWorker,
            OccupiedThreads = maxWorker - availableWorker
        };
    }

Agora, quando fazemos 29 chamadas simultâneas para o ponto de extremidade Test / Get, leva quase 11 segundos para obter êxito em todas as solicitações. Portanto, o servidor executa todas as solicitações simultaneamente em 11 threads. Para ver o status dos threads, fazer uma chamada para Test / ThreadInfo logo após fazer uma chamada para Test / Get retorna imediatamente (sem esperar) {"AvailableWorkerThreads": 8161, "MaxWorkerThreads": 8191, "OccupiedThreads": 30}

Parece que 29 threads estão executando solicitações de Teste / Obtenção e 1 thread está executando uma solicitação de Test / ThreadInfo.

Quando faço 60 chamadas para Test / Get, leva quase 36 segundos para obter sucesso. Fazer uma chamada para Test / ThreadInfo (leva algum tempo) retorna {"AvailableWorkerThreads": 8161, "MaxWorkerThreads": 8191, "OccupiedThreads": 30}

Se aumentarmos o número de solicitações, o valor de OccupiedThreads aumenta. Como para 1000 solicitações, são necessários 2 min 22 seg e o valor de OccupiedThreads é 129.

Parece solicitar e ficar na fila após 30 chamadas simultâneas, embora muitos threads estejam disponíveis no WorkerThread. Gradualmente, aumenta o encadeamento para execução simultânea, mas isso não é suficiente (129 para 1000 solicitações).

Como nossos serviços têm muitas chamadas de E / S (algumas são chamadas de API externas e outras são consultas de banco de dados), a latência também é alta. Como estamos usando todas as chamadas de E / S de forma assíncrona, o servidor pode atender muitas solicitações simultaneamente, mas precisamos de mais simultaneidade quando o processador estiver realizando um trabalho. Estamos usando o plano de serviço S2 com uma instância. O aumento da instância aumentará a simultaneidade, mas precisamos de mais simultaneidade da instância única.

Depois de ler algum blog e documentação no IIS, vimos que existe uma configuraçãominFreeThreads. Se o número de threads disponíveis no pool de threads estiver abaixo do valor dessa configuração, o IIS começará a enfileirar a solicitação. Existe algo no appservice como este? E é realmente possível obter mais simultaneidade do serviço de aplicativo azul ou estamos perdendo alguma configuração lá?