He escrito una API usando asp.net webapi y la implementé en azul como Appservice. El nombre de mi controlador es TestController y mi método de acción es similar al siguiente.

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

Por lo tanto, para cada solicitud, debe esperar 10 segundos antes de devolver el "valor" de la cadena. También he escrito otro punto final para ver la cantidad de subprocesos en el conjunto de subprocesos que funcionan para ejecutar solicitudes. Esa acción es algo como abajo.

    [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
        };
    }

Ahora, cuando hacemos 29 recibir llamadas al mismo tiempo en el punto final Test / Get, se necesitan casi 11 segundos para que todas las solicitudes tengan éxito. Entonces el servidor ejecuta todas las solicitudes simultáneamente en 11 hilos. Para ver el estado de los subprocesos, hacer una llamada a Test / ThreadInfo justo después de hacer una llamada a Test / Get devuelve inmediatamente (sin esperar) {"AvailableWorkerThreads": 8161, "MaxWorkerThreads": 8191, "OccupiedThreads": 30}

Parece que 29 subprocesos están ejecutando solicitudes Test / Get y 1 subproceso está ejecutando la solicitud Test / ThreadInfo.

Cuando hago 60 recibir llamadas a Test / Get, tarda casi 36 segundos en tener éxito. Hacer una llamada a Test / ThreadInfo (toma algún tiempo) devuelve {"AvailableWorkerThreads": 8161, "MaxWorkerThreads": 8191, "OccupiedThreads": 30}

Si aumentamos el número de solicitudes, aumenta el valor de OccupiedThreads. Al igual que para 1000 solicitudes, toma 2 min 22 segundos y el valor de OccupiedThreads es 129.

Parece solicitar y ponerse en cola después de 30 llamadas simultáneas, aunque muchos subprocesos están disponibles en WorkerThread. Gradualmente aumenta el hilo para la ejecución concurrente, pero eso no es suficiente (129 para 1000 solicitudes).

Como nuestros servicios tienen muchas llamadas IO (algunas de ellas son llamadas API externas y otras son consultas de bases de datos), la latencia también es alta. Como estamos utilizando todas las llamadas IO de forma asíncrona, el servidor puede atender muchas solicitudes al mismo tiempo, pero necesitamos más concurrencia cuando el procesador está haciendo un trabajo real. Estamos utilizando el plan de servicio S2 con una instancia. El aumento de la instancia aumentará la concurrencia, pero necesitamos más concurrencia de una sola instancia.

Después de leer un blog y documentación sobre IIS, hemos visto que hay una configuraciónminFreeThreads. Si el número de subprocesos disponibles en el grupo de subprocesos cae por debajo del valor de esta configuración, IIS comienza a poner en cola la solicitud. ¿Hay algo en appservice como este? ¿Y es realmente posible obtener más concurrencia del servicio de aplicaciones azure o nos falta alguna configuración allí?