HttpListener de subprocesos múltiples con aguardar asíncrono y tareas

Question

¿Sería este un buen ejemplo de un HttpListener escalable con múltiples subprocesos?

¿Es así como por ejemplo un IIS real lo haría?

public class Program 
{ 
    private static readonly HttpListener Listener = new HttpListener(); 

    public static void Main() 
    { 
     Listener.Prefixes.Add("http://+:80/"); 
     Listener.Start(); 
     Listen(); 
     Console.WriteLine("Listening..."); 
     Console.WriteLine("Press any key to exit..."); 
     Console.ReadKey(); 
    } 

    private static async void Listen() 
    { 
     while (true) 
     { 
      var context = await Listener.GetContextAsync(); 
      Console.WriteLine("Client connected"); 
      Task.Factory.StartNew(() => ProcessRequest(context)); 
     } 

     Listener.Close(); 
    } 

    private static void ProcessRequest(HttpListenerContext context) 
    { 
     System.Threading.Thread.Sleep(10*1000); 
     Console.WriteLine("Response"); 
    } 
} 

Estoy buscando específicamente una solución escalable que NO dependa de IIS. En cambio, solo en http.sys (que es la clase httplistener): la razón para no confiar en iIS es porque el gobierno. el área en la que trabajo requiere un área de ataque extremadamente reducida.

Answer 1

He hecho algo similar en https://github.com/JamesDunne/Aardwolf y he hecho algunas pruebas exhaustivas al respecto.

Consulte el código en https://github.com/JamesDunne/aardwolf/blob/master/Aardwolf/HttpAsyncHost.cs#L107 para la implementación del ciclo de eventos centrales.

Me parece que utilizar un Semaphore para controlar cuántas solicitudes concurrentes GetContextAsync están activas es el mejor enfoque. Esencialmente, el ciclo principal continúa ejecutándose hasta que el semáforo bloquea el hilo debido a que se ha alcanzado el conteo. Entonces habrá N concurrente "conexión acepta" activa. Cada vez que se acepta una conexión, se libera el semáforo y puede tomar una nueva solicitud.

Los valores de recuento inicial y máximo del semáforo requieren un ajuste fino, dependiendo de la carga que espera recibir. Es un acto de equilibrio delicado entre la cantidad de conexiones simultáneas que espera frente a los tiempos de respuesta promedio que desean sus clientes. Los valores más altos significan que se pueden mantener más conexiones a un tiempo de respuesta promedio mucho más lento; Se rechazarán menos conexiones. Los valores más bajos significan que se pueden mantener menos conexiones a un tiempo de respuesta promedio mucho más rápido; más conexiones serán rechazadas.

He encontrado, experimentalmente (en mi hardware), que los valores alrededor de 128 permiten que el servidor maneje grandes cantidades de conexiones simultáneas (hasta 1.024) en tiempos de respuesta aceptables. Pruebe usando su propio hardware y ajuste sus parámetros en consecuencia.

También encontré que a una sola instancia de WCAT no le gusta manejar más de 1,024 conexiones en sí. Por lo tanto, si se toma en serio la prueba de carga, utilice varias máquinas cliente con WCAT en su servidor y asegúrese de probar a través de una red rápida, p. 10 GbE y que los límites de su sistema operativo no lo están desacelerando. Asegúrese de probar en las SKU de Windows Server porque las SKU de escritorio están limitadas de manera predeterminada.

Resumen: Cómo escribe su ciclo de aceptación de conexión es fundamental para la escalabilidad de su servidor.

Answer 2

Técnicamente tienes razón. Para hacerlo escalable, probablemente desee tener múltiples GetContextAsync ejecutándose al mismo tiempo (se necesitan pruebas de rendimiento para saber exactamente cuántos, pero "unos pocos para cada núcleo" es probablemente la respuesta correcta).

Entonces, naturalmente, como se señala en los comentarios; no usar IIS significa que debe ser bastante serio acerca de la seguridad de muchas cosas que IIS le brinda "de forma gratuita".

Answer 3

Sé que soy tremendamente tarde para la fiesta en esto, pero publiqué una biblioteca (fuente aquí https://github.com/jchristn/WatsonWebserver) en NuGet que encapsula un servidor web asíncrono.