[omniORB] General Performance Strategy Questions...

[Ridgway, Richard (London)]

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.
--------------------------------------------------------