> > I mean allowing an unlimited amount of connections (as much as the
process
> > table will allow) that are served in a round-robin basis by oracle,
much
> > like an httpd process. I'm tired of having to up the number of user
> > connections just because we get an unprecedented surge in interest
from
> > people viewing all of our sites.
> How about doing -N 5000? Or a equally-big
> your-webserver-will-melt-down-before-the-number-is-achieved.
Whether that would be advantageous depends on what happens when the max
number of backends is reached. If a new incoming connection simply waits
for a new backend to become available, then you can do about the same
thing as connection-pooling by simply setting a low number of backends - a
number somewhere around the number of CPU's that you have. In theory, you
keep each CPU full (assuming there aren't other bottlenecks), but avoid
the extra memory usage and context-switching cost associated with a larger
number of backends. However, it would block incoming requests, meaning
that a few large queries could stop a few hundred small, fast queries from
running. That means that the guy generating traffic statistics can keep
several hundred people from seeing your site until he's done - a bad
thing. : )
Overall, it seems (to me, at least) that if new connections (above the
max) simply wait, then a good compromise would be limitting the number of
backends to a level several times greater than the number of CPU's that
you have, so that a single (or a few) large query doesn't completely
monopolize the system, yet not so high that you're going to exhaust your
memory or run into other problems associated with huge numbers of running
processes.
steve
