|Subject:||Re: Thread pooling, server optimization performances.|
|Posted by:||Lokki (unkno…@recipient.yes)|
|Date:||Thu, 15 Sep 2005|
> Have you experienced similar problems?
Yes, TIdSchedulerOfThreadPool didn't work for me from the beginning of Indy
"the bun" <rosario.carbo…@flare.co.uk> wrote in message
>I have already posted this post to the support but probably someone of you
>has experience in thread pooling and server optimization performances.
> I have a short lived connection server which has many connections
> simultanuely and then we concern about performances and want to reuse
> threads kept in a pool instead of freeing them, for example 15 threads.
> In Indy 9 we used TIdThreadMgrPool into the ThreadMgr property of a
> TIdTCPServer and it worked well.
> With Indy 10 ThreadMgr doesn't exist anymore and we have a scheduler
> property now, all right? Now reading the documentation Indy specifies that
> the TIdSchedulerOfThreadDefault is the default thread management, but
> there is no example code, does it mean it is automatically handled by the
> server with no implementation of code? I don't understand.
> Another possibility is the use of the component TIdSchedulerOfThreadPool
> which according to the
> documentation you should assign to the scheduler, but you can't do it at
> design time or you have an access violation when you free the server, it
> doesn't work at all because whatever you assign in its properties
> MaxThreads and PoolSize the threads are never freed and then causes a
> memory leak.
> The documentation says that it is planned that this component will be
> improved in the future, has it been improved?
> Here is my code anyway, which I need to modify in order to avoid the
> memory leak:
> FIdTCPServer: TIdTCPServer;
> FIdThreadMgrPool: TIdSchedulerOfThreadPool;
> procedure TfrmEngineMain.FormCreate(Sender: TObject);
> FIdTCPServer.ContextClass := TECLTEThread;
> FIdTCPServer.Scheduler := FIdThreadMgrPool;
> The memory leak is caused because the destructor of the custom thread
> class (TECLTEThread) is never called, if I don't use any scheduler (if I
> don't set anything in this property) the destructor is called any time a
> thread has finished, freeing then the memory.
> N.B. The PoolSize property is set to 0 (as suggested by the documentation)
> and MaxThreads is set to 15 (but could be set to anything).
> P.S. The Indy version installed is 10.0.20, the documentation is probably
> newer respect to the release.
> Have you experienced similar problems? Have you some example code?
> Rosario Carbone
Thread pooling, server optimization performances. posted by the bun on Thu, 15 Sep 2005