On Fri, Sep 20, 2002 at 06:27:31PM +0100, Philip Martin wrote:
> mark benedetto king <bking@Inquira.Com> writes:
>
> > In effect, ra_dav -> NetBDB would *leverage* the MPM features of
> > apache; the fewer times apache forks, the fewer NetBDB services
> > would be required.
>
> Really, I'd have thought you need at least one NetBDB per thread. Are
> you proposing that threads share a NetBDB connection? Assuming you
> really mean one per thread, how often does Apache create and destroy
> threads?
>
> Using one NetBDB per thread will dramatically increase the number of
> proceses, which kind of negates any benefits of using threads instead
> of processes.
>
There are several different possibilities. One approach that works well
for database access is to use a "connection pool". When a thread wants
to opens a connection, it first looks in the pool to see if any
previously established connections are available. If not, it creates
a new one (unless the total number of outstanding connections has
exceeded a configurable threshold, in which case it blocks until
a new connection becomes available). In any case, it uses the connection
it obtains, and when done, places it into the list of available
connections. Frequently this list has a configurable maximum size;
if more than X connections are already available, this one is
simply closed.
Another mechanism would be to share connections between threads. This
requires significantly more synchronization than the above approach, so
at high levels of concurrency, performance will degrade significantly.
Blending these two approaches is another possibility (i.e., share
N connections between M threads, M > N).
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 20 19:57:35 2002