-none- 2007-10-02 - By Greg Rahn
Back
I'm not certain of disaster, but I think the odds are surely in the
house's favor. I doubt that this application has a requirement for
10000 *active* database connections. For whatever reason, the
application seems to be written in such manner that it does not
leverage connection pooling. I'll discuss under these assertions.
First, I'd think that there would be an extreme amount of overhead for
a kernel to manage 10000 open TCP connections. I personally do not
have any data, but if anyone does, I'd be interested in hearing about
it.
Second, Oracle is a processed based application. Having 10000
(dedicated) db connections means that there is over 10000 db processes
running on this host. I'm not a kernel guru, but its probably likely
that not too many Unix operating systems are tested with that scale of
processes. To me, it seems like a considerable amount of process time
slicing to manage. This is why connection pooling is a more scalable
option.
Niall Litchfield mentioned memory. Since each db connection has
private memory space, the amount of memory consumed by 10000 is
probably not insignificant.
There are probably more challenges than just the ones that I've noted.
I'm sure the community would love to hear about them as this exercise
take place.
On 9/25/07, David Sharples <davidsharples@(protected)> wrote:
> why a recipe for disaster?
>
> On 25/09/2007, Greg Rahn <greg@(protected)> wrote:
> > Having 10,000 database connections on a given node (regardless of
> > size) is probably a recipe for failure. Have you considered using a
> > connection pool?
> > http://en.wikipedia.org/wiki/Connection_Pool
--
Regards,
Greg Rahn
http://structureddata.org
--
http://www.freelists.org/webpage/oracle-l
|
|
