2010-05-05 11 views
7

Descubrí que al configurar la propiedad ConnectTimeoout para un componente TIdHTTP, hace que las solicitudes (GET y POST) sean aproximadamente 120ms más lentas?Delphi: ¿Por qué IdHTTP.ConnectTimeout hace que las solicitudes sean más lentas?

¿Por qué es esto, y puedo evitar/eludir esto de alguna manera?

Sobre: ​​D2010 con componentes Indy enviados, todas las actualizaciones instaladas para D2010. OS es WinXP (32 bits) SP3 con la mayoría de los parches ...

Mi rutina de sincronización es:

Procedure DoGet; 
    Var 
     Freq,T1,T2 : Int64; 
     Cli  : TIdHTTP; 
     S   : String; 
    begin 
     QueryPerformanceFrequency(Freq); 
     Try 
      QueryPerformanceCounter(T1); 
      Cli := TIdHTTP.Create(NIL); 
      Cli.ConnectTimeout := 1000; // without this we get < 15ms!! 
      S := Cli.Get('http://127.0.0.1/empty_page.php'); 
     Finally 
      FreeAndNil(Cli); 
      QueryPerformanceCounter(T2); 
     End; 
     Memo1.Lines.Add('Time = '+FormatFloat('0.000',(T2-T1)/Freq)); 
    End; 

Con el conjunto ConnectTimeout en el código consigo promedio. tiempos de 130-140ms, sin alrededor de 5-15ms ...

Respuesta

14

Cuando ConnectTimeout es cero (y TIdAntifreeze no está activo), Indy simplemente se conecta. De lo contrario, TIdIOHandlerStack.ConnectClient llama a DoConnectTimeout, que crea un nuevo hilo para hacer la conexión, mientras que el hilo de llamada duerme y procesa las operaciones , esperando que se establezca la conexión. Si no hay conexión antes de que transcurra el tiempo de espera, arroja una excepción.

Los hilos no son libres, y el hilo de llamada siempre dormirá antes de comprobar si el hilo de conexión ha realizado su tarea. La duración predeterminada del sueño es 125 ms. (Para usar otra cosa, active TIdAntifreeze y establezca su propiedad IdleTimeout por debajo de 125.)

+2

"el hilo que llama siempre dormirá antes de verificar si el hilo de conexión ha realizado su tarea". Eso era cierto en las versiones antiguas, pero eso no ha sido así desde marzo de 2008. –

+0

"Eso era cierto en las versiones antiguas, pero eso no ha sido así desde marzo de 2008". - y eso es bueno, ya que el comportamiento anterior debería considerarse (y probablemente ha sido) un error. – TheBlastOne

+0

Lamento responder a esta pregunta, pero estoy usando 10.2 Tokio y estoy experimentando el mismo comportamiento que el OP, 10-15ms de tiempo de conexión sin tiempo de espera, 130-140ms con. Por lo tanto, parece que "el hilo de llamada siempre dormirá antes de verificar si el hilo de conexión ha cumplido su tarea" sigue siendo actual. – Bozzy

Cuestiones relacionadas