[omniORB] General Performance Strategy Questions...

Ridgway, Richard (London) Richard_Ridgway at ml.com
Mon Aug 13 09:03:37 BST 2007


The 256 is probably an artificial limit, but going much above that you
will tend to hit performance problems in the server. What platform are
you on? The file descriptor limit is platform dependant. What is your
max no. file descriptors? There's a hard threshold and a soft threshold
- you won't be able to change the hard upper limit without privileged
access. 'lsof' will tell you what file descriptors you have open and let
you see them (& count them!).

sh-3.00$ ulimit -a
open files                      (-n) 1024
stack size              (kbytes, -s) 10240

The other thing worth checking is that you aren't allocating a 10Mb
stack for each thread (as is default for me), as that would quickly get
out of hand. 'pmap' shows this (look for 256 chunks of 10mb!)

I actually use TAO on the server side, and only use omniorb (through
python) as a client side orb - so there may be a hard limit of 256 in
there somewhere, but I very much doubt it.


-----Original Message-----
From: Sean Parker [mailto:supinlick at yahoo.com] 
Sent: 13 August 2007 01:53
To: Ridgway, Richard (London); omniorb-list at omniorb-support.com
Subject: RE: [omniORB] General Performance Strategy Questions...



Thanks Richard for your reply. I was looking more for
OS-level (or changes I can make to omniORB and recompile)
that would allow more than the apparent 256 threads. Does
this limit sound familiar? I had been playing with various
permutations of thr/conn, thr policy, idle conn timeouts,
etc. and there seems to be a 256 thread ceiling.

  I had recently set the setrlimit() libc function, for
increasing the # open file handles, and that seemed to
help. Is that the only real thing I can aside from
redesigning my server?

  Thanks
    Sean


--- "Ridgway, Richard (London)" <Richard_Ridgway at ml.com>
wrote:

> I recommend jacorb rather than sun for the Java ORB.
> There's plenty of
> tuning available there. I've no personal experience with
> the Sun ORB,
> but I haven't heard anything good about it...
> 
> Quick browse of the omniorb manual indicates
> maxServerThreadPoolSize is
> probably what you need.
> 
> 
> -----Original Message-----
> From: omniorb-list-bounces at omniorb-support.com
> [mailto:omniorb-list-bounces at omniorb-support.com] On
> Behalf Of Sean
> Parker
> Sent: 10 August 2007 21:45
> To: omniorb-list at omniorb-support.com
> Subject: [omniORB] General Performance Strategy
> Questions...
> 
> 
> 
> Hello - 
> 
>   (Duncan - I haven't resolved the GIOP error issue yet -
> it doesn't seem to be IDL-mismatch, but I've got bigger
> fish to fry right now. "-ORBstrictIIOP 0" keeps us going
> for now... and I don't think it's related to the issue
> below, since I've had these performance problems way
> before
> the GIOP error came up)
> 
>   Thanks to OminORB for being as good as it is - we're
> pounding the hell out of it, and I think I need to start
> optimizing things in order for us to have a well-behaved
> system. Our system is basically 100+ servers (RH 9 and
> above) with ~200 CORBA servers (many identical.)
> 
>   We have a SystemMonitor that collects data from each
> server, and a DataRepository that most servers post data
> to. Needless to say the SystemMonitor and DataRepository
> are hurting unless I do something NOW to relieve the
> pressure :-)
> 
>   We have ~ 5 Java applications, using Sun's canned ORB
> to
> access the SystemMonitor for status also. One of them is
> a
> Servlet running in Tomcat. The problem seems to be that
> the
> SystemMonitor is so busy COLLECTING data, (and the rest
> of
> the system is verifying that the SystemMonitor is up, so
> they ping the SystemMonitor occasionally and pushing
> monitor data) that the Servlet accesses to get monitor
> data
> for display fail, even though the monitor seems to be up
> and running. (i.e. Transient exc, for example)
> 
>   I presume this is a timeout due to inability to obtain
> a
> connection on the SystemMonitor. Is this likely? I setup
> the SystemMonitor to free up connections as fast as
> possible: scanGranularity=1, inConScanPeriod=1,
> outConScanPeriod=1. (is this doing what I think it
> should?)
> Does anyone have experience with any issues between Sun's
> ORB and OmniORB that may raise it's ugly head on this
> issue? 
> 
> *****
> As a side question, I can't find any info on tuning Sun's
> ORB (Thanks Duncan for all of OmniORB's options), like
> timeouts, etc. Any info you know of?
> *****
> 
>   In general, what's the best way to ensure that a
> server,
> that will be pounded, will most-likely be able to service
> as many connections as possible, especially when each
> method call is quick to return? Also, how would I go
> about
> increasing the number of threads allowed, so I can
> increase
> the thread/connection combination above 256? (I'm
> allowing
> only 1 or 2 threads/connection, since it's likely that
> any
> client won't be pegging the SystemMonitor from more than
> one thread)
> 
>   I suppose you people are like "what the hell is he
> doing"? or "that's a silly design"? or "he should do
> this..." Any suggestions appreciated.
> 
> 
>   Thanks and God Bless
>     Sean
> 
> 
> 
> 
> 
> 
> God Bless 
>     Sean Parker 
> 
> 
> 
> 
> 
>  
>
________________________________________________________________________
> ____________
> Fussy? Opinionated? Impossible to please? Perfect.  Join
> Yahoo!'s user
> panel and lay it on us.
>
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
> 
> 
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
>
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> --------------------------------------------------------
> 
> This message w/attachments (message) may be privileged,
> confidential or proprietary, and if you are not an
> intended recipient, please notify the sender, do not use
> or share it and delete it. Unless specifically indicated,
> this message is not an offer to sell or a solicitation of
> any investment products or other financial product or
> service, an official confirmation of any transaction, or
> an official statement of Merrill Lynch. Subject to
> applicable law, Merrill Lynch may monitor, review and
> retain e-communications (EC) traveling through its
> networks/systems. The laws of the country of each
> sender/recipient may impact the handling of EC, and EC
> may be archived, supervised and produced in countries
> other than the country in which you are located. This
> message cannot be guaranteed to be secure or error-free.
> This message is subject to terms available at the
> following link:
> http://www.ml.com/e-communications_terms/. By messaging
> with Merrill Lynch you consent to the foregoing.
> --------------------------------------------------------
> 





God Bless 
    Sean Parker 





       
________________________________________________________________________
____________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:
mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC
--------------------------------------------------------

This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
--------------------------------------------------------



More information about the omniORB-list mailing list