From: Bill on
On Mar 28, 3:34 pm, Frank van Bortel <frank.van.bor...(a)gmail.com>
wrote:
> Bill wrote:
> > Hi, yes it's a performance issue.
>
> > Last year we hit max processes. This I believe was because it wasn't
> > releasing the connections to AD fast enough.
>
> > Unfortunately, I didn't get an opportunity at the time to see where
> > the resources were being used, though our UNIX admin said there that
> > from the OS point of view, most of the CPU was being used for the
> > binding to AD accounts.
>
> Which were probably due to the number of sessions. Not running with
> multiple dispatchers, are you?
> If you were, one (of a few) dispatchers would handle all connections.
> Now - every connection is a dedicated process
>
> --
>
> Regards, Frank van Bortel
>
> Topposting in Usenet groups I regard as offensive - I will not reply

We're not using Shared Server, just dedicated processes and letting
the three application servers deal with the connection pooling.

There's enough RAM to startup shared server and allocate lots of
memory to it but I've read negatives about Shared Server and if the
apps servers are doing the pooling maybe it negates the need for it.

My initial thought was to increase the processes parameter.
From: Vladimir M. Zakharychev on
On Mar 28, 10:47 pm, Bill <billshatne...(a)googlemail.com> wrote:
> On Mar 28, 3:34 pm, Frank van Bortel <frank.van.bor...(a)gmail.com>
> wrote:
>
>
>
> > Bill wrote:
> > > Hi, yes it's a performance issue.
>
> > > Last year we hit max processes. This I believe was because it wasn't
> > > releasing the connections to AD fast enough.
>
> > > Unfortunately, I didn't get an opportunity at the time to see where
> > > the resources were being used, though our UNIX admin said there that
> > > from the OS point of view, most of the CPU was being used for the
> > > binding to AD accounts.
>
> > Which were probably due to the number of sessions. Not running with
> > multiple dispatchers, are you?
> > If you were, one (of a few) dispatchers would handle all connections.
> > Now - every connection is a dedicated process
>
> > --
>
> > Regards, Frank van Bortel
>
> > Topposting in Usenet groups I regard as offensive - I will not reply
>
> We're not using Shared Server, just dedicated processes and letting
> the three application servers deal with the connection pooling.
>
> There's enough RAM to startup shared server and allocate lots of
> memory to it but I've read negatives about Shared Server and if the
> apps servers are doing the pooling maybe it negates the need for it.
>
> My initial thought was to increase the processes parameter.

And that would be correct decision: you should estimate the number of
concurrent sessions (maximum number of users attempting to log into
the system simultaneously) and multiply that by approx. 1,3 to
accommodate for background processes and activity spikes. You should
also estimate time needed for single AD authentication to succeed and
take that delay into account (the session doing the auth will be
unavailable for anything else at least for the duration of the
operation, so your app server will need to add new connection to the
pool when another request arrives.) You app server should also be
configured to be able to open that much simultaneous connections to
the database (that is, if your PROCESSES is, say, 100, but app server
connection pool size is 50 then you will need to bump up the maximum
pool size to 80-85.)

With initial configuration in place, you may want to do a load test to
check if your app server and database are capable to cope with the
load while maintaining acceptable response times. There are tools out
there to automate load testing (Quest Benchmark Factory, for example.)
You might then be able to tweak the configuration to minimize response
times and consumed server resources. For example, configure the app
server to keep a number of reserved (open, but inactive) database
connections in the pool to be able to use them immediately without
having to wait for Oracle background process startup during activity
spikes. This number would be just enough to satisfy average acceptable
response time requirement without overallocating database sessions
that would rarely or never be used. As the number of users of your
system changes, you will revise this configuration with the goal of
keeping response times and server resource consumption at their
minimums.

Regards,
Vladimir M. Zakharychev
N-Networks, makers of Dynamic PSP(tm)
http://www.dynamicpsp.com
From: Bill on
Thanks for the replies, folks. Useful info.