🚀 go-pugleaf

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.