Delphi: Warum IdHTTP.ConnectTimeout Anfragen langsamer?

Entdeckte ich, dass bei der Festlegung der ConnectTimeoout Eigenschaft für eine TIdHTTP-Komponente, macht es die Anfragen (GET und POST) werden über 120ms langsamer?

Warum ist das so und kann ich das vermeiden/das irgendwie umgehen?

Env: D2010 mit ausgeliefert Indy-Komponenten, alle updates installiert für D2010. OS ist WinXP (32bit) SP3 mit den meisten patches...

Mein timing-routine:

    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;

Mit der ConnectTimeout set in code bekomme ich avg. mal von 130-140ms, ohne es über die 5-15ms ...

InformationsquelleAutor K.Sandell | 2010-05-05
  1. 14

    Wenn ConnectTimeout null ist (und TIdAntifreeze ist nicht in Kraft), Indy verbindet einfach. Ansonsten TIdIOHandlerStack.ConnectClient Anrufe DoConnectTimeout, die erstellt einen neuen thread zu tun, die Verbindung während der aufrufende thread schläft und Prozesse TIdAntifreeze Operationen, warten Sie für die Verbindung eingerichtet werden. Wenn es nicht eine Verbindung durch die Zeit der timeout abgelaufen ist, wirft er eine exception.

    Threads sind nicht frei, und der aufrufende thread wird immer schlafen, bevor Sie prüfen, ob das Anschlussgewinde hat es geschafft, seine Aufgabe. Die Standard-Schlaf Dauer ist 125 ms. (Sie etwas anderes zu verwenden, aktivieren TIdAntifreeze und seine IdleTimeout Eigenschaft niedriger als 125.)

    • "der aufrufende thread wird immer schlafen, bevor Sie prüfen, ob das Anschlussgewinde hat es geschafft, in seiner Aufgabe". Das war schon in den alten Versionen, aber das ist nicht wahr, seit März 2008.
    • "Das war schon in den alten Versionen, aber das ist nicht wahr, seit März 2008." - und das ist eine gute Sache, da die älteren Verhalten sollte (und wohl auch wurde) als ein bug.
    • Sorry für bump, diese Frage, aber ich bin mit 10.2 Tokyo und ich bin mit dem gleichen Verhalten wie der OP, 10-15ms Verbindung mal ohne timeout, 130-140ms mit. So scheint es, "der aufrufende thread wird immer schlafen, bevor Sie prüfen, ob das Anschlussgewinde hat es geschafft, seine Aufgabe" ist immer noch aktuell.
    InformationsquelleAutor Rob Kennedy
Schreibe einen Kommentar