Re: 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

Comment on Re: DB Connection pool

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]
Re: Re: Re: DB Connection pool by samtregar (Abbot) on May 07, 2002 at 18:12 UTC
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]


We don't bite newbies here... much
	PerlMonks