🚀 go-pugleaf

Frank Gruber schrieb:
> I'm experincing the following problem.
> As soon as I set the ConnectTimeout property of the IdHttp component my 
> application is significantly slowing down on performance. It does no 
> matter which value it is set to. Any ideas what is causing this. Setting 
> the read timeout property instead has no influence on perfomance.

Addition:

I measured the time the Post method takes by calling GetTicksCount 
directly before and after the call:

1) without setting ConnectTimout: 10 - 15 ms
2) with setting ConnectTimout: 100 - 120 ms

Wow.
Frank.

"Frank Gruber" <ZJQBBYSESPEZ@spammotel.com> wrote in message
news:444d23f3$1@newsgroups.borland.com...

> As soon as I set the ConnectTimeout property of the IdHttp
> component my application is significantly slowing down on
> performance.

What EXACTLY do you consider "significant"?  What are the actual numbers you
are seeing?

In order to implement a connect timeout for a blocking socket, TIdTCPClient
has to spawn a worker thread to handle the timeout.  Your performance issue
is likely caused by that.  When the timeout is not used, and there is no
TIdAntiFreeze component on the form, then no thread is used at all.

> Setting the read timeout property instead has no influence on perfomance.

The ReadTimeout property has nothing to do with the connect timeout.


Gambit

Remy Lebeau (TeamB) schrieb:

> What EXACTLY do you consider "significant"?  What are the actual numbers you
> are seeing?

See my second post.
It's a 100 ms delay for every connect what I call significant.

> In order to implement a connect timeout for a blocking socket, TIdTCPClient
> has to spawn a worker thread to handle the timeout.  Your performance issue
> is likely caused by that.  When the timeout is not used, and there is no
> TIdAntiFreeze component on the form, then no thread is used at all.

That explains what's going on. The app is a presentation server which 
receives http browser request and dynamically builds the html responses. 
The necessary data it queries from an applications server via multiple 
idhttp requests (xml over http). As there is a 100 ms delay for every 
connect (for spawning the required timeout thread) it all sums together 
to a noticeable delay.

I should consider redesigning that part of the app to have one thread 
which is monitoring the connect timeout in all idhttp components of all 
other threads and avoid using the ConnectTimeout property. What do you 
think?

What exactly is the ConnectTimeout for. I would assume it is for an 
incomplete "three way tcp handshake" but not sure about that?

Thanks for you help.

Frank.

"Frank Gruber" <HVFDMIPUMFPS@spammotel.com> wrote in message
news:444dfc73@newsgroups.borland.com...

> I should consider redesigning that part of the app to have one thread
> which is monitoring the connect timeout in all idhttp components of all
> other threads and avoid using the ConnectTimeout property. What do you
> think?

If you are making requeries to the same server(s) each time, then you might
consider using HTTP keep-alives, so that the connections are not dropped
after each request and thus don't need to be reconnected each time.

> What exactly is the ConnectTimeout for.

Exactly what its name suggests it is - a timeout for Connect().  If
Connect() does not establish a connection before the timeout elapses, then
the socket is closed and an exception is thrown.

> I would assume it is for an incomplete "three way tcp handshake"
> but not sure about that?

No.


Gambit

Remy Lebeau (TeamB) schrieb:

> If you are making requeries to the same server(s) each time, then you might
> consider using HTTP keep-alives, so that the connections are not dropped
> after each request and thus don't need to be reconnected each time.

Design of the application does not make this possible I think. However I 
will think about it, thanks.

BTW: looking into the sources seem to tell me a different story about 
the performance difference.

LSleepTime := 125;
IdGlobal.Sleep(LSleepTime);

If a timeout is given the main-thread checks in a loop for a successful 
connection. At the beginning of the loop there is a delay of 125ms 
before each check for success. Not to bad for the internet but for 
intranet apps not optimal. I think I will customize the Indy sources at 
that point.

Regards,
Frank.

"Frank Gruber" <ZJQBBYSESPEZ@spammotel.com> wrote in message 
news:444e5b9b$1@newsgroups.borland.com...
> BTW: looking into the sources seem to tell me a different story about the 
> performance difference.
>
> LSleepTime := 125;
> IdGlobal.Sleep(LSleepTime);
>
> If a timeout is given the main-thread checks in a loop for a successful 
> connection. At the beginning of the loop there is a delay of 125ms before 
> each check for success. Not to bad for the internet but for intranet apps 
> not optimal. I think I will customize the Indy sources at that point.

I am afraid that is bad programming on the part of the Indy team. They have a 
lot of work to do at the moment, what with trying to get Indy 10 to work with 
C++ at all! So, this probably won't be fixed any time soon.
-- 

Mark Jacobs
DK Computing
http://www.dkcomputing.co.uk

Mark Jacobs schrieb:
> "Frank Gruber" <ZJQBBYSESPEZ@spammotel.com> wrote in message 
> news:444e5b9b$1@newsgroups.borland.com...
>> BTW: looking into the sources seem to tell me a different story about the 
>> performance difference.
>>
>> LSleepTime := 125;
>> IdGlobal.Sleep(LSleepTime);
>>
>> If a timeout is given the main-thread checks in a loop for a successful 
>> connection. At the beginning of the loop there is a delay of 125ms before 
>> each check for success. Not to bad for the internet but for intranet apps 
>> not optimal. I think I will customize the Indy sources at that point.
> 
> I am afraid that is bad programming on the part of the Indy team. They have a 
> lot of work to do at the moment, what with trying to get Indy 10 to work with 
> C++ at all! So, this probably won't be fixed any time soon.

Not a problem at all. Fixed it myself meanwhile. I'm quite happy with 
Indy, as I have the sources I can fix what does not meet my requirements.

Frank.

"Mark Jacobs" <http://www.jacobsm.com/mjmsg?Borland%20Newsgroup> wrote in
message news:4451e679@newsgroups.borland.com...

> I am afraid that is bad programming on the part of the Indy team.

What would you suggest as an alternative?


Gambit

Remy Lebeau (TeamB) schrieb:
> "Mark Jacobs" <http://www.jacobsm.com/mjmsg?Borland%20Newsgroup> wrote in
> message news:4451e679@newsgroups.borland.com...
> 
>> I am afraid that is bad programming on the part of the Indy team.
> 
> What would you suggest as an alternative?

The following is what I changed to meet my requirements. However there 
may be others saying it is bad programming also.

procedure TIdIOHandlerSocket.ConnectClient(const AHost: string;
   const APort: Integer; const ABoundIP: string; const ABoundPort,
   ABoundPortMin, ABoundPortMax: Integer; const ATimeout: Integer = 
IdTimeoutDefault);

   procedure ConnectTimeout(ATimeout: Integer);
   const
     LSleepTimes: array[0..8] of Integer = (1, 2, 5, 10, 20, 20, 50, 
100, 125);
   var
     LSleepTime: Integer;
     LInfinite: Boolean;
     LSleepIndex: Integer;
   begin
     LInfinite := ATimeout = IdTimeoutInfinite;
     LSleepIndex := 0;
     with TIdConnectThread.Create(True) do try
       FBinding := Binding;
       Resume;
       // Sleep
       if TIdAntiFreezeBase.ShouldUse then begin
         LSleepTime := Min(GAntiFreeze.IdleTimeOut, 125);
       end else begin
         LSleepTime := LSleepTimes[LSleepIndex];
       end;

       if LInfinite then begin
         ATimeout := LSleepTime + 1;
       end;

       while ATimeout > LSleepTime do begin
         IdGlobal.Sleep(LSleepTime);
         ATimeout := ATimeout - LSleepTime;

         if not TIdAntiFreezeBase.ShouldUse then begin
           if (LSleepIndex < 8) then begin
             LSleepIndex := LSleepIndex + 1;
             LSleepTime := LSleepTimes[LSleepIndex];
           end;
         end;

         if LInfinite then begin
           ATimeout := LSleepTime + 1;
         end;

         TIdAntiFreezeBase.DoProcess;
         if Terminated then begin
           ATimeout := 0;
           Break;
         end;
       end;
       if ATimeout > 0 then
         IdGlobal.Sleep(ATimeout);
       //
       if Terminated then begin
         if Length(FExceptionMessage) > 0 then begin
           if FLastSocketError <> 0 then begin
             raise EIdSocketError.CreateError(FLastSocketError, 
FExceptionMessage);
           end else begin
             raise EIdConnectException.Create(FExceptionMessage);
           end;
         end;
       end else begin
         Terminate;
         Close;
         WaitFor;
         raise EIdConnectTimeout.Create(RSConnectTimeout);
       end;
     finally Free; end;
   end;