Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: TIdTcpServer performance: TIdSchedulerOfThreadPool


This question is not answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 1 - Last Post: Apr 26, 2017 1:09 PM Last Post By: Remy Lebeau (Te...
Vincent V.

Posts: 10
Registered: 1/2/10
TIdTcpServer performance: TIdSchedulerOfThreadPool  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Apr 26, 2017 6:25 AM
Hi,

I have a server application with a TIdTCPServer, and currently 350 clients are connecting to this server (and each client can open extra temporary dataconnections ). Right now, when I have to do a restart of my application, all 350 clients connect at the same moment. With TIdTCPServer creating a thread for every connection this causes 350 threads to be created at once (putting load on the main thread I assume) and once connected, each connection needs to get authenticated which takes a little more CPU time (but this time from the connections's thread). Anyway, the user interface becomes non responsive during 60" right after startup, I think the main reason is the thread creation.

For the future, this number of connections will continue to grow, so I think that having a thread per connection is not the best option anymore?
Is it possible to run a TIdTCPServer with 350 concurrent (permanent) connections while only having 100 threads? Is this what TIdSchedulerOfThreadPool (or TIdSchedulerOfThreadDefault) would do? Or are they caching threads instead of destroying them, and will I still have 350 threads for my 350 connections? What's an 'acceptable' maximum number of threads a server should have nowadays?

Right now, I experimented by increasing the TIdTCPServer.MaxConnections by 5 each second until it reaches 300. This works fine, but is there a better solution?
Thanks for any advice!
Vincent

(PS: I found a very similar question here ( [https://forums.embarcadero.com/message.jspa?messageID=696924|https://forums.embarcadero.com/message.jspa?messageID=696924] ) , but my questions were not exactly the same and the topic was from 2015 so I posted a new topic).
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: TIdTcpServer performance: TIdSchedulerOfThreadPool  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Apr 26, 2017 1:07 PM   in response to: Vincent V. in response to: Vincent V.
Vincent wrote:

With TIdTCPServer creating a thread for every connection this causes
350 threads to be created at once (putting load on the main thread I
assume)

Nope, the main thread is not involved at all.

Anyway, the user interface becomes non responsive during 60" right
after startup, I think the main reason is the thread creation.

More likely, you are just bombarding the UI thread with too many UI updates
at one time.

For the future, this number of connections will continue to grow, so I
think that having a thread per connection is not the best option
anymore?

That depends on what your client threads are actually doing. You could have
thousands of client threads running and system performance would be minimal
if those are mostly sitting idle waiting for input from the clients. If you
need to support many thousands of concurrent clients, then yes, this model
does not scale well, you should use non-blocking/asychronous socket I/O instead
(which Indy does not support).

Is it possible to run a TIdTCPServer with 350 concurrent (permanent)
connections while only having 100 threads?

Officially, that functionality was never implemented in the main Indy library.
Each connection runs in a dedicated thread.

Unofficially, that functionality was implemented in an optional add-on package
named SuperCore, which introduced a fiber-based scheduler for TIdTCPServer,
running each connection in a fiber instead of a thread, running multiple
fibers in a single thread. However, that effort didn't work out in the long
run, and the project was adandoned (though the code still exists, but hasn't
been updated in several years. See Indy's \Lib\SuperCore source folder).

Is this what TIdSchedulerOfThreadPool (or TIdSchedulerOfThreadDefault)
would do?

No.

TIdSchedulerOfThreadDefault is the default scheduler. It creates a new thread
when a client connects, and destroys the thread when the client disconnects.

TIdSchedulerOfThreadPool caches idle threads in a list, and fills the cache with
initial idle threads at startup. When a client connects, it creates a new thread only
if an idle thread is not already available in the cache. When a client disconnects,
its thread is put to sleep and added to the cache if there is available room for it.
This doesn't reduce the number of threads running concurrently at a time, but it
does reduce the time needed to create and setup threads.

Or are they caching threads instead of destroying them

TIdSchedulerOfThreadPool does, yes.

and will I still have 350 threads for my 350 connections?

Yes (if not a few more threads, depending on your pool size).

What's an 'acceptable' maximum number of threads a server should
have nowadays?

You have to measure your server's performance to determine what is
appropriate for your own needs.

--
Remy Lebeau (TeamB)
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02