in reply to DB Connection pool

Are you sure this will help? Unless your database server has multiple processors it is unlikely that running multiple queries in parallel will be substantially faster than running the same queries serially.

If you do have multiple processors on your database server, then my suggestion would be to fork() N processes to each do 1/N of the work (N = number of available processors). Each process can then establish a private database connection, saving you the trouble of dealing with connection pools.

Of course, more complicated schemes are possible but they are unlikely to be worth the effort.

-sam

Replies are listed 'Best First'.
Re: Re: DB Connection pool
by dsheroh (Monsignor) on May 07, 2002 at 14:37 UTC
    Unless your database server has multiple processors it is unlikely that running multiple queries in parallel will be substantially faster than running the same queries serially.

    Not necessarily true. Compiling a large project (say, a linux kernel) on a single CPU machine completes substantially faster with two processes (make -j2 ...) than it does in a single process, as this allows the CPU to keep compiling in one process while the other waits for disk access.

    While I haven't tested whether this is also true of databases, I suspect that it is likely to be.

[reply]
[d/l]
      My experience with databases is that they are far less I/O bound than many other tasks. As long as your machine has sufficient free RAM and your database is properly tuned, your queries should not be waiting for disk access often enough to matter.

      Of course, it's worth testing. It might be that the proper setting for N is actually 2 * number of available CPUs.

      -sam

[reply]

In Section Seekers of Perl Wisdom