[omniORB] Thread and connection policy for very large configurations

[Serguei Kolos]

Hi

Thank you for the replay.

>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.
>
For me the option 3 with the patch you mentioned looks very promising.

>
>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?  
>
Even if the clients can do this, this does not solve the problem with the
number of connections. What I have learned using just pure TCP/IP is
that the server running on powerful machine (PIV2GHz) can handle 2000
connections if it will keep them always open. If 2000 clients will need to
reopen connection for each call, this will never work even with the less
request rate. TCP connection opening is an expensive operation and
a large number of simultaneous connection requests to the same server
produce a huge delays on some clients.

>Perhaps you could develop a
>patch for using poll(), and make it either a build-time or run-time
>configuration option.
>
This is probably a good idea. But what happens when the new version of the
omniORB appears? I guess I'll need to rewrite my patch.
Could it be done in a different way - could the OMNI itself provides an 
API for
setting up a custom implementation of the socket multiplexor at run-time?
In this case I can write my own multiplexor based on the poll and set it up
if necessary instead of the default, select based one.
Alternatively one could say that the SocketCollection class (which
implements the socket multiplexor) is the API that one could use to
implement his own multiplexor. In this case it would be good to have some
kind of garantee that this interface will not be touched in the next OMNI
releases.

Cheers,
Sergei

>  
>