[omniORB] NameServer capacity

[Joel Schuster]

This is a multi-part message in MIME format.
--------------606CA8EE780154479A5FFF49
Content-Type: text/plain; charset=UTF-7
Content-Transfer-Encoding: 7bit

Along these same lines...
Is there any feature within OmniOrb that could load balance
between multiple servers? Or would I have to modify the 
NameServer to handle even simple load balancing like
a round-robin?

Joel


"Gary D. Duzan" wrote:
> 
> 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
--------------606CA8EE780154479A5FFF49
Content-Type: text/x-vcard; charset=UTF-7;
 name="jmschust.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Joel Schuster
Content-Disposition: attachment;
 filename="jmschust.vcf"

begin:vcard 
n:Schuster;Joel
tel;fax:(719) 548-5092
tel;home:(719) 570-1759
tel;work:(719) 266-5300 X118
x-mozilla-html:TRUE
org:Computer and Communication Technologies
version:2.1
email;internet:jschuster@cctus.com
adr;quoted-printable:;;5450 Tech Center Drive=0D=0ASuite 410	;Colorado Springs;CO;80919-2339;USA
x-mozilla-cpt:jmschust.cctus.com;30368
fn:Joel Schuster
end:vcard

--------------606CA8EE780154479A5FFF49--