¿Por qué Thread.Sleep() es tan intensivo en la CPU?

Question

que tienen una página ASP.NET con este código pseduo:

while (read) 
{ 
    Response.OutputStream.Write(buffer, 0, buffer.Length); 
    Response.Flush(); 
} 

Cualquier cliente que solicita esta página comenzará a descargar un archivo binario. Todo está bien en este momento, pero los clientes no tenían límite de velocidad de descarga, por lo que cambió el código anterior para esto:

while (read) 
{ 
    Response.OutputStream.Write(buffer, 0, buffer.Length); 
    Response.Flush(); 
    Thread.Sleep(500); 
} 

problema de la velocidad se resuelve ahora, pero bajo prueba con 100 clientes simultáneos que se conectan una tras otra (3 segundos retraso entre cada nueva conexión) el uso de la CPU aumenta cuando aumenta el número de clientes y cuando hay entre 70 y 80 clientes simultáneos, la CPU alcanza el 100% y se rechaza cualquier conexión nueva. Los números pueden ser diferentes en otras máquinas pero la pregunta es ¿por qué Thread.Sleep() es tan intensivo en la CPU y hay alguna forma de acelerar el cliente sin que la CPU se eleve?

Puedo hacerlo a nivel IIS pero necesito más control desde el interior de mi aplicación.

Answer 1

Sólo una conjetura:

no creo que es Thread.Sleep() que está atando la CPU - es el hecho de que usted está haciendo que los hilos por atar responder a una solicitud de tanto tiempo, y las necesidades del sistema para activar nuevos subprocesos (y otros recursos) para responder a las nuevas solicitudes, ya que esos subprocesos de espera ya no están disponibles en el grupo de subprocesos.

Answer 2

En lugar de una página ASP.NET debe implementar un IHttpAsyncHandler. El código de página ASP.NET pone muchas cosas entre su código y el navegador que no serían apropiadas para transferir archivos binarios. Además, dado que está intentando realizar una limitación de velocidad, debe utilizar un código asíncrono para limitar el uso de recursos, lo que sería difícil en una página ASP.NET. Crear un IHttpAsyncHandler es bastante simple. Simplemente active algunas operaciones asincrónicas en el método BeginProcessRequest, y no olvide cerrar correctamente el contexto para mostrar que ha llegado al final del archivo. IIS no podrá cerrarlo aquí.

El siguiente es mi ejemplo realmente malo de cómo realizar una operación asincrónica que consta de una serie de pasos, que van del 0 al 10, cada uno realizado en un intervalo de 500 ms.

using System; 
using System.Threading; 

namespace ConsoleApplication1 { 
    class Program { 
     static void Main() { 
      // Create IO instances 
      EventWaitHandle WaitHandle = new EventWaitHandle(false, EventResetMode.AutoReset); // We don't actually fire this event, just need a ref 
      EventWaitHandle StopWaitHandle = new EventWaitHandle(false, EventResetMode.AutoReset); 
      int Counter = 0; 
      WaitOrTimerCallback AsyncIOMethod = (s, t) => { }; 
      AsyncIOMethod = (s, t) => { 
       // Handle IO step 
       Counter++; 
       Console.WriteLine(Counter); 
       if (Counter >= 10) 
        // Counter has reaced 10 so we stop 
        StopWaitHandle.Set(); 
       else 
        // Register the next step in the thread pool 
        ThreadPool.RegisterWaitForSingleObject(WaitHandle, AsyncIOMethod, null, 500, true); 
      }; 

      // Do initial IO 
      Console.WriteLine(Counter); 
      // Register the first step in the thread pool 
      ThreadPool.RegisterWaitForSingleObject(WaitHandle, AsyncIOMethod, null, 500, true); 
      // We force the main thread to wait here so that the demo doesn't close instantly 
      StopWaitHandle.WaitOne(); 
     } 
    } 
} 

También tendrá que registrar su aplicación IHttpAsyncHandler con IIS en cualquier forma apropiada para su situación.

Answer 3

Echemos un vistazo a si la respuesta de Michael parece razonable.

Ahora, Michael sabiamente señala que Thread.Sleep(500) no debería costar mucho en el camino de la CPU. Eso está muy bien en teoría, pero veamos si eso sale bien en la práctica.

static void Main(string[] args) { 
     for(int i = 0; i != 10000; ++i) 
     { 
      Thread.Sleep(500); 
     } 
    } 

Al ejecutar esto, el uso de la CPU de la aplicación oscila alrededor del 0%.

Michael también señala que dado que todos los hilos que ASP.NET tiene que utilizar están durmiendo, tendrá que generar nuevos hilos, y ofrece que esto es costoso. Vamos a tratar de no dormir, pero haciendo un montón de desove:

static void Main(string[] args) { 
     for(int i = 0; i != 10000; ++i) 
     { 
      new Thread(o => {}).Start(); 
     } 
    } 

Creamos un montón de hilos, pero que acaba de ejecutar una operación nula. Eso usa mucha CPU, aunque los hilos no están haciendo nada.

Sin embargo, la cantidad total de hilos nunca es muy alta, ya que cada uno vive durante un tiempo tan corto. Deja para combinar los dos:

static void Main(string[] args) { 
     for(int i = 0; i != 10000; ++i) 
     { 
      new Thread(o => {Thread.Sleep(500);}).Start(); 
     } 
    } 

La adición de esta operación que hemos demostrado a ser baja en el uso de la CPU a cada hilo aumenta el uso de CPU aún más, a medida que aumentan los hilos arriba. Si lo ejecuto en un depurador, sube hasta cerca del 100% de la CPU. Si lo ejecuto fuera de un depurador, funciona un poco mejor, pero solo porque arroja una excepción de falta de memoria antes de que tenga la oportunidad de alcanzar el 100%.

Por lo tanto, no es Thread.Sleep en sí mismo ese es el problema, pero el efecto secundario de tener todos los subprocesos disponibles obliga a crear más y más hilos para manejar otro trabajo, tal como dijo Michael.

Answer 4

Es porque el hilo recibe un aumento de prioridad cada vez que cede su porción de tiempo. Evite llamar a dormir a menudo (especialmente con valores bajos).