No problem, glad it made sense. Let me go through your batch...
At 11:49 PM 11-11-99 -0500, [EMAIL PROTECTED] wrote:
>Bless you Edwin! Thanks heaps for having a go at that one!
>
>Your reasoning made perfect sense and was very easy to follow.
>
>Can you stand one last batch of questions?!
>
>1. The 5th "rule of thumb" in Lidia's document says:
>
> > In our testing we find is best to have 115% more
> > total DS clients than total CP clients.
>
>So that means we should bump up our DS # of workers to 35. Do you agree?
I don't see any reason to have more DSw threads than CPw threads. It won't
hurt though.
>2. In the Command Center....the RDBMS Service "Worker Properties" tab has 6
>settings. Based on what you & the rule of thumb said, can you tell me how
>to set
>them? (BTW, my database is Informix 7.) Here's my guess:
>
> Max DB connections per process 35
> Max DB connections per DB 35
> Max records to retrieve 5000
> # of worker processes 35
> Port # 0
> Max # of clients per worker 1
Are you sure Informix' client is not thread safe? In that case your
settings are correct, assuming all users use the same login for the DB. The
max db connection/process can be set to 1, but 35 won't hurt, it will never
be reached though.
>3. You said :
> > make sure the workers are all in their own process,
> > which is also the case for the PE service.
>
>The "PE Service" has 2 tabs offering the following options, and here's how we
>have them set:
> Service Properties - "run Service in a seperate process?" NO
> Worker Properties - "is Global Session PE?" YES
>
>Should we change the "Service Properties...run Service in a seperate process?"
>to YES?
yep, also, add -Djava.compiler= , to disable the JIT ( issue with some
events on the session) Maybe you can use -nojit, depends on the version
you're running. Check to see if your Java VM supports -nojit, if it doesn't
, use the -D option i mentioned
>4. Same thing for the CP Service, we have the tabs set like this:
> Service Properties - "run Service in a seperate process?" NO
> Worker Properties - "run Worker in a seperate process?" YES
>
>Does that look good?
yep
>5. On the RDBMS Service, only the "Service Properties" tab asks about "run
>Service in a seperate process?". We have it set to NO. Is that OK?
yep, all services, except the PE , should be run in the same process
>6. Lastly, you wrote:
> > That should do it, at least if...the hardware can handle it.
>
>Can you tell me how I'd know if the hardware can handle it? My box is an HP-UX
>v10.x, but I don't know the memory/disk/speed specs. Can you tell me what
>would
>be a nice h/w config?
Just check how much memory you DSw and CPw eat up. Add it all up and add
another 100 Mb . I can't give you a clearcut HW config. You'll have to
test one , and tweak it, and test it again. The main issue will probably be
memory. In which case you'll have to downscale you setup, i.e. have a few
less DB connection and CPw threads . Just always make sure #CPw threads <=
#DSw threads.
>Edwin or others, I owe you a BIG favor if you can help me any of these Qs!
there you go :)
>Thanks again,
>Janet
>
>
>
>
>
> (Embedded
> image moved Edwin van der Sanden <[EMAIL PROTECTED]>
> to file: 11/11/99 07:26 PM
> pic06278.pcx)
>
>
>
>
>To: Janet Traub/IS/SSC/THD,
> [EMAIL PROTECTED]
>cc:
>Subject: Re: [ND] No Free workers
>
>
>
>
>Hi Janet,
>
>I'll have a go at it, don't hang me up on the numbers though.Judging from your
>current settings , you're running against an Oracle DB , so you can only
>have 1
>DB connection / DB worker process.
>
>so we got a 1000 regular users and 70 admins
>first, let's say the admins are twice as active as the normal ones. This gives
>1140 user, which rounds up to 1200.
>
>1200 users.
>I'm assuming around 0.5 seconds average processing time / request
>we want around 2 seconds for average response time
>so 1 thread can virually handle 4 concurrent clients
>1200 users send 1 req. every 10 seconds
>so that's 120 req/s
>we will need 120/4= 30 threads to handle those
>
>We will want 30 CPw threads , and 30 DSw threads
>So, for the CP : 2 CPw , 15 clients/w
>So, for the DS : 30 DSw , 1 clients/w
>
>make sure the workers are all in their own process, which is also the case for
>the PE service. That should do it, at least , if the assumptions are
>correct and
>the hardware can handle it.
>
>hth.
>
>Cheers,
>Edwin.
>
>
>
>
>
>
>
>
>Quoting [EMAIL PROTECTED]:
>
> >
> >
> > Hi Lidia, thanks for the doc. It would be great if it could include a real
> > world
> > example!
> >
> > Would anyone like to take a stab at offering some # based on my scenario:
> >
> > - 1000 users will be using this app mainly between 7AM-7PM
> > - most all of them will be using it on a daily basis to fill out their
> > timesheets,
> > - 70 ADMIN users will be heavier users approving time charges weekly, and
> > creating & budgeting workplans, and running reports.
> >
> > Our current CP Service settings of:
> > # of workers = 2 (running out of process)
> > Max # of clients per worker = 4
> >
> > do seem rather low to me. But what might be more reasonable?
> > My uneducated guess:
> > # of workers = 5 (running out of process)
> > Max # of clients per worker = 10
> >
> > And for the RDBMS Service, we currently have:
> > # of workers = 16 (running out of process)
> > Max # of clients per worker = 1
> > max # DB connectoins per process = 25
> > max # DB connections per DB = 25
> >
> > Any comment on how they look?
> >
> > Thanks very much for your help!
> > Janet
> >
> >
> >
> >
> > (Embedded
> > image moved Lidia Marchioni <[EMAIL PROTECTED]>
> > to file: 11/11/99 06:44 PM
> > pic05200.pcx)
> >
> >
> >
> >
> > To: Janet Traub/IS/SSC/THD
> > cc: nd4 forum
> > <[EMAIL PROTECTED]>
> > Subject: Re: [ND] No Free workers
> >
> >
> >
> >
> > Just to confirm:
> >
> > "No free workers" indicates that the (# cp workers * max clients per CP
> > worker)
> > has
> > been exceeded. Under normal circumstances, this should only occur if the
> > number
> > of
> > concurrent clients accessing the system exceeds the above number.
> >
> > and here, mostly from the ND5 documentation:
> >
> > Tuning the Worker Pool
> > For important services such as the Connection Processor and Data Service,
> > the
> > NetDynamics Command Center allows fine grained tuning of the worker pool.
> > For
> > each
> > component there are three properties that can greatly affect system
> > performance:
> >
> > 1 NumberOfWorkers: dictates the size of the worker pool.
> >
> > 2 MaximumClientsPerWorker: indicates the maximum number of clients that can
> > simultaneously access a single worker instance.
> >
> > 3 NumberOf Processes: indicates the number of processes over which the
> > workers
> > are
> > distributed.
> >
> >
> > Here are some general rules of thumb and observations about these
> > properties:
> >
> > 1 CP Workers will always be out-of-process. In a deployment operation,
> > workers
> > should
> > run in their own process for both performance and fault tolerance (for
> > example,
> > a CP
> > worker running a project can crash and bring down the entire server if it
> > is
> > running
> > in the same process as the SM).
> >
> > 2 Usually there will be only a single CP worker per process (namely
> > NumberOfProcesses
> > equals workers). The NetDynamics services (the CP and DS) are designed so
> > that
> > there
> > is no reason to run multiple workers in a single process. Instead the
> > MaxClientsPerWorker should be tuned, and each worker should run in its own
> > process.
> >
> > 3 MaxClientsPerWorker * number of workers per process dictates the number
> > of
> > threads
> > that will be running in a process. Depending on your system and how it
> > context
> > switches, it may be better to have many concurrent processes than many
> > concurrent
> > threads. For example, 1 worker with a max clients of 100 indicates that 100
> > threads
> > could potentially be active in the worker process. On the other hand, 10
> > workers
> > with
> > 10 clients each indicates that only 10 threads will be active in each
> > worker
> > process.
> >
> > 4 NumberOfWorkers * MaxClientsPerWorker dictates the maximum number of
> > clients
> > that
> > can simultaneously access the component. This is important. If there are 2
> > workers
> > and 5 clients per worker for the CP service, then only 10 CGI clients can
> > access
> > the
> > system in parallel. (The other clients will wait for a free worker to
> > become
> > available.) On the other hand, if there are 5 workers and 100 clients per
> > worker, 500
> > concurrent clients (and potentially 100 concurrent threads per worker) can
> > be
> > supported; however, depending on the hardware, 500 concurrent clients may
> > actually
> > degrade performance due to thrashing and thread context switching.
> >
> > 5 Ratio of CP MaxClients/DS MaxClients- You should never have fewer total
> > DS
> > MaxClients than CP MaxClients. This is because of a reservation revocation
> > that
> > can
> > occur when there are fewer total DS clients than total CP clients. In our
> > testing we
> > find is best to have 115% more total DS clients than total CP clients.
> >
> > Lidia
> >
> >
> > [EMAIL PROTECTED] wrote:
> >
> > > Hi folks, I searched the archives and TechNotes but couldn't find any
> > answers
> > > about this one
> > >
> > > We have about 20 users piloting our ND4 app that runs on HP-UX. The ND4
> > app
> > > server stopped responding today and when I looked in the
> > smDefaultPartition.log
> > > I saw this message
> > >
> > > **************SM is started*****************
> > > exception CNdNoFreeWorkersException{string reason="no free workers";}
> > > at
> > >
> >
>netdyn.cosi.service.loadBalancing.CNdLoadBalancingManager.allocateWorker(Co
>mpile
>d
> >
> > >
> > > Code)
> > > at netdyn.cosi.service.CNdServiceImpl.allocateWorker(Compiled Code)
> > > at netdyn.cosi.stubs._tie_INdService.allocateWorker(Compiled Code)
> > > at netdyn.cosi.stubs._INdServiceImplBase._execute(Compiled Code)
> > > at netdyn.cosi.stubs._INdServiceImplBase._execute(Compiled Code)
> > > at com.visigenic.vbroker.orb.SkeletonDelegateImpl.execute(Compiled
> > Code)
> > > at com.visigenic.vbroker.orb.GiopProtocolAdapter.doRequest(Compiled
> > Code)
> > > at
> > com.visigenic.vbroker.orb.GiopProtocolAdapter.dispatchMessage(Compiled
> > > Code)
> > > at com.visigenic.vbroker.orb.ThreadPoolDispatcher.run(Compiled Code)
> > > at com.visigenic.vbroker.orb.WorkerThread.run(Compiled Code
> > >
> > > and that "no free workers" junk was repeated 8 times.
> > >
> > > I chked our CP service settings...and I see we have:
> > > # of workers = 2
> > > max # clients per worker = 4
> > >
> > > (Hmnn, 2 x 4 = 8...is that why it was repeated 8 times?)
> > >
> > > Questions:
> > > Does it seem likely that with only 20 total users (and most likely no
> > more
> > then
> > > 10 of them accessing the app concurrently) we would hit a "no free
> > worker"
> > > problem?
> > >
> > > Could the scarcity of memory/space on the HP server box contribute to
> > this
> > > problem?
> > >
> > > If anyone has a decent understanding of this, could you please shed some
> > light
> > > on this?
> > >
> > > Thanks!
> > > Janet
> > >
> > > _________________________________________________________________________
> > >
> > > For help in using, subscribing, and unsubscribing to the discussion
> > > forums, please go to: http://www.netdynamics.com/support/visitdevfor.html
> > >
> > > For dire need help, email: [EMAIL PROTECTED]
> >
> > _________________________________________________________________________
> >
> > For help in using, subscribing, and unsubscribing to the discussion
> > forums, please go to: http://www.netdynamics.com/support/visitdevfor.html
> >
> > For dire need help, email: [EMAIL PROTECTED]
> >
> >
> >
>
>
>
>Greets,
>Edwin van der Sanden,
>NetEd.
>
>web : www.neted.nl
>mail : [EMAIL PROTECTED]
>mobile: +31-6-55866016
>
>
_________________________________________________________________________
For help in using, subscribing, and unsubscribing to the discussion
forums, please go to: http://www.netdynamics.com/support/visitdevfor.html
For dire need help, email: [EMAIL PROTECTED]
