It's very unlikely that you'll reach 10000 connections. Anyhow, go to the official source. (Emphasis mine).
If persistent connections don't have
any added functionality, what are
they good for?
The answer here is extremely simple --
efficiency. Persistent connections are
good if the overhead to create a link
to your SQL server is high. Whether or
not this overhead is really high
depends on many factors. Like, what
kind of database it is, whether or
not it sits on the same computer on
which your web server sits, how
loaded the machine the SQL server sits
on is and so forth. The bottom line
is that if that connection overhead is
high, persistent connections help you
considerably. They cause the child
process to simply connect only once
for its entire lifespan, instead of
every time it processes a page that
requires connecting to the SQL server.
This means that for every child that
opened a persistent connection will
have its own open persistent
connection to the server. For example,
if you had 20 different child
processes that ran a script that made
a persistent connection to your SQL
server, you'd have 20 different
connections to the SQL server, one
from each child.
Note, however, that this can have some
drawbacks if you are using a database
with connection limits that are
exceeded by persistent child
connections. If your database has a
limit of 16 simultaneous connections,
and in the course of a busy server
session, 17 child threads attempt to
connect, one will not be able to. If
there are bugs in your scripts which
do not allow the connections to shut
down (such as infinite loops), the
database with only 16 connections may
be rapidly swamped. Check your
database documentation for information
on handling abandoned or idle
connections.
