[omniORB] Thread and connection policy for very large configurations

Wed Apr 2 15:54:02 2003

I'm not sure how well the server would keep up under the best of connection
and thread models, but I can tell you what I've learned.  There are three
configurations possible

1. Thread per connection.  Actually there is an upper limit on number of
connections you set which will convert the strategy to thread pool.  With
more than 1024 connections expected, I doubt you want that many threads.

2. Thread pool, with connection watching.  This means that once a thread is
serving one connection, it will watch that connection for a short period of
time to see if an additional request comes in.  If several clients pound
the server with requests, all of the threads may end up serving a minority
of clients while the rest have to wait.

3. Thread pool, without connection watching.  As soon as a thread finishes
a request, it goes immediately to the thread pool.  Unfortunately, the
connection is left unwatched for a short period of time after the thread
returns to the pool.  This means if a client sends a burst of several
requests back to back, there is a fixed lag between each request getting
assigned to a thread.  I think on the order of 20 ms.  If your clients
really don't send more than 1 request per second, you won't notice this
issue.

So the choices are: Too many threads, possible starvation, or possible high
request latency.

I've got a patch, that I didn't end up using in production, that solves the
latency problem in configuration 3.  It only works on Unix like systems
since it uses a pipe to wake up the thread watching all the connections.
Duncan would like a solution that works on Windows too, but I didn't try to
find one.  My systems aren't likely to trigger starvation, so I use
configuration 1 or 2.  I simply can't suffer the latency in configuration
3.

I'm not sure how to deal with more than 1024 connections.  I've never had
that many clients that are actively pounding a single server.  Could the
clients send larger, less frequent requests?  Perhaps you could develop a
patch for using poll(), and make it either a build-time or run-time
configuration option.

good luck,
Kendall

                      Serguei Kolos                                                                                                     
                      <Serguei.Kolos@cern.ch>            To:       omniorb-list@omniorb-support.com                                     
                      Sent by:                           cc:                                                                            
                      omniorb-list-admin@omniorb-        Fax to:                                                                        
                      support.com                        Subject:  [omniORB] Thread and connection policy for very large configurations 

                      04/02/2003 02:09 AM                                                                                               

Hi

I 'am thinking of using the omniORB for my project, but there is one point
I want to understand.
I have to implement a CORBA server which is able to handle 2000 concurrent
clients with each client sending short request to this server once per
second.
What thread (or connection) model I should use to have efficient
implementation???
On one hand it's relatively clear that the most suitable one is the
ThreadPool.
Fine, but what about number of simultaneous connections? Closing and
opening
connection each second for each clients will kill my server. On the
other hand,
as far as I know, the omniORB use internally the select system call
which does not
work with socket id > 1024 (without recompilation of the OS kernel). So
that my
server can not keep all the connections open simultaneously.
Could anyone advice me what I can do in this situation?
By the way, don't you think that using the poll instead of the select in
the omniORB core
might be a good idea? Poll has the same efficiency and overhead as
select but does not
have the 1024 limitation.

Cheers,
Sergei

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