2010-05-05 16 views
7

Ho scoperto che quando si imposta la proprietà ConnectTimeoout per un componente TIdHTTP, le richieste (GET e POST) diventano più lente di circa 120 ms?Delphi: Perché IdHTTP.ConnectTimeout rende le richieste più lente?

Perché è questo, e posso evitare/bypassare questo in qualche modo?

Env: D2010 con componenti Indy forniti, tutti gli aggiornamenti installati per D2010. OS è WinXP (32bit) SP3 con la maggior parte delle patch ...

La mia routine di sincronizzazione è:

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 il set ConnectTimeout nel codice ottengo avg. tempi di 130-140 ms, senza che sia circa 5-15 ms ...

risposta

14

Quando ConnectTimeout è zero (e TIdAntifreeze non è in vigore), Indy si connette semplicemente. In caso contrario, chiamate DoConnectTimeout, che crea una nuova discussione per la connessione mentre il thread di chiamata è inattivo ed elabora le operazioni TIdAntifreeze, in attesa che venga stabilita la connessione. Se non c'è connessione entro la scadenza del timeout, si genera un'eccezione.

I thread non sono gratuiti e il thread chiamante si interromperà sempre prima di verificare se il thread di connessione ha completato il proprio compito. La durata di sospensione predefinita è 125 ms. (Per utilizzare qualcos'altro, attiva e imposta la sua proprietà IdleTimeout inferiore a 125.)

+2

"il thread chiamante si addormenta sempre prima di verificare se il thread di connessione ha completato il suo compito". Questo era vero nelle vecchie versioni, ma ciò non era vero da marzo 2008. –

+0

"Questo era vero nelle vecchie versioni, ma ciò non era vero dal marzo 2008." - e questa è una buona cosa dal momento che il comportamento più vecchio dovrebbe essere (e probabilmente è stato) considerato un bug. – TheBlastOne

+0

Siamo spiacenti di rispondere a questa domanda, ma sto usando 10.2 Tokyo e sto vivendo lo stesso comportamento dell'OP, tempo di connessione 10-15 ms senza timeout, 130-140 ms con. Quindi sembra che "il thread chiamante dormirà sempre prima di verificare se il thread di connessione ha completato il suo compito" è ancora attuale. – Bozzy

Problemi correlati