Re: DBMS_LDAP
Date: Mon, 29 Mar 2010 00:06:54 -0700 (PDT)
Message-ID: <9eae733e-e4d9-4094-8118-a27f3053a64e_at_g19g2000yqe.googlegroups.com>
On Mar 28, 10:47 pm, Bill <billshatne..._at_googlemail.com> wrote:
> On Mar 28, 3:34 pm, Frank van Bortel <frank.van.bor..._at_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
Received on Mon Mar 29 2010 - 02:06:54 CDT