[omniORB] NameServer capacity

[Gary D. Duzan]

In Message <3A9389CB.6F5626BF@anemosky.com> ,
   Pletyak Attila <attila.pletyak@anemosky.com> wrote:

=>Thank you. Let me ask a question regarding this, as I feel now that I am
=>not that professional in CORBA.

   That's ok. I haven't actually done this sort of thing myself,
so you should probably look for other opinions on the matter
before doing a final design.

=>You are right, we will have CGIs running on different web servers. Is it
=>enough, then, to have an object on every web server which simply routes
=>the asks to the correct object in the background, and gives back the
=>answer of that object? Or something more sophisticated is needed on this
=>proxy method?

   That's the sort of thing I was thinking of, yes. Keep in mind
that every time the CGI starts it is going to open a TCP connection
to the server(s) to handle any CORBA calls. On the server side, it
will have to start a new thread for the connection, dispatch the
call, return the result, and wait for new calls on the connection.
In a CGI environment, this is likely not to happen, so the connection
will eventually be closed and the thread reclaimed. If the hit rate
is high enough, this excess connection (and thread) management
could bog down the server. (Of course, if the rate is low then
there may not be an immediate problem, but if there is even a chance
of growth then it is a good idea to design for scalability if you
can.) If the CGI is talking to a persistent proxy on its own web
server, the connection management load is spread across them and
each proxy can maintain a small number of relatively persistent
connections to the main server(s). This can also help deal with
thread and connection limits since you are only dealing with a
fraction of the calls at each proxy.
   That said, you should do some performance testing on your own
to see how well your system does under load from multiple busy web
servers.  What I've said is mostly educated guesswork; it is always
better to have real observations of a real system.  A simulation
based on Python/omniORBpy could give you a rough idea and shouldn't
be too difficult or time consuming to build. Try running with and
without the proxy and see how it does at different hit rates.

=>I saw some proxy objects generated in the stubs of omniORB but this
=>cannot be a compass for me as Duncan mentioned previosly.

   No, that is the omniORB internal implementation which is unrelated.

					Gary Duzan
					Verizon Laboratories