[omniORB] thread pool vs. thread per connection

Mon Nov 25 19:20:01 2002

Hate to reply so quick to my own message, but I was a bit hasty.  I'm now
studying the omniAsyncInvoker, which is a pool of idle threads, or intends
to be.  Empirically I am seeing excessive thread creation, but I haven't
tracked down why yet, since it looks like the invoker should hold on to
threads even after the giopWorker is done.

Any comments are still welcome.

Kendall

                    baileyk@schneider.com                                                                                    
                    Sent by:                           To:     omniorb-list@omniorb-support.com                              
                    omniorb-list-admin@omniorb-s       cc:                                                                   
                    upport.com                         Fax to:                                                               
                                                       Subject:     Re: [omniORB] thread pool vs. thread per connection      

                    11/25/2002 12:49 PM                                                                                      

This is related to my previous post regarding the performance of omniNames
with different thread handling configurations.  That post mentioned a 5ms
vs 500ms measured time for a sequence of calls.  The latest tests I've run
puts it closer to 5ms vs 225ms in a more controlled test environment.
Still a big difference.

I've done a quick scan of the giopServer.cc code which handles the thread
policy.  It appears that the thread pool policy does not refer to a pool of
idle threads.  Other thread pools I've worked with and written myself have
involved the worker threads blocking on a condition variable, and one or
more would be signaled to start some job (or take over as leader).  When
the job is done, the thread returns to the pool by waiting on the condition
variable again.  In omniORB's thread pool, the worker threads die as soon
as they've finished a job and there are no pending jobs to start.  A new
thread is created for each request if the job queue is always empty.
What's being called a thread pool policy looks to be a thread per request
policy, but with thread reuse when a high water mark is reached.

Is anyone else depending on the thread pool policy added to omniORB4, and
seeing excessive thread creation?  If my analysis is correct, is there
interest in an "idle" thread pool policy to reduce the number of threads
created and destroyed?

My concern stems from this scenario:  a J2EE client tier ( servlet/JSP )
hitting a C++ omniORB server.  The Java ORB multiplexes calls over a small
number (possible one?) connection, but we need highest performance
possible.  Some requests should take only 5-10ms while others may take
several seconds.   Number of concurrent requests could be large (10 - 15?).
Thread creation/destruction overhead is not acceptable.  I suspect this
isn't a unique role for omniORB to want to play in.

Thanks,
Kendall

_______________________________________________
omniORB-list mailing list
omniORB-list@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list