Delphi: Why does IdHTTP.ConnectTimeout make requests slower?

Question

I discovered that when setting the ConnectTimeoout property for a TIdHTTP component, it makes the requests (GET and POST) become about 120ms slower?

Why is this, and can I avoid/bypass this somehow?

Env: D2010 with shipped Indy components, all updates installed for D2010. OS is WinXP (32bit) SP3 with most patches...

My timing routine is:

    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;

With the ConnectTimeout set in code I get avg. times of 130-140ms, without it's about 5-15ms ...

Olympus

Answer 1

When ConnectTimeout is zero (and TIdAntifreeze is not in effect), Indy simply connects. Otherwise, TIdIOHandlerStack.ConnectClient calls DoConnectTimeout, which creates a new thread to do the connecting while the calling thread sleeps and processes TIdAntifreeze operations, waiting for the connection to be established. If there's not connection by the time the timeout elapses, it throws an exception.

Threads aren't free, and the calling thread will always sleep before checking whether the connection thread has accomplished its task. The default sleep duration is 125 ms. (To use something else, activate TIdAntifreeze and set its IdleTimeout property lower than 125.)

Domination

"the calling thread will always sleep before checking whether the connection thread has accomplished its task". That was true in old versions, but that has not been true since March 2008. – Hipparchus

"That was true in old versions, but that has not been true since March 2008." -- and that's a good thing since the older behavior should be (and probably has been) considered a bug. – Merkel

Sorry to bump this question, but I'm using 10.2 Tokyo and I'm experiencing the same behaviour as the OP, 10-15ms connection time without timeout, 130-140ms with. So it seems "the calling thread will always sleep before checking whether the connection thread has accomplished its task" is still current. – Chequered