Hi, On Fri, Nov 07, 2008 at 03:24:00PM +0100, B. F. wrote: > I have recently started using the mod_dbd module for database > connection handling in my own module and a had slight hope that it > would perform better than a classic persistent connection approach. > > Basically I am using the ap_dbd_acquire(request_rec*) function in a > handler function (in my own module) and then uses some of the apr_dbd > functions to fetch data from a PostgreSQL database, all this seems > fine. > > When I run a performance test (using httperf) with the prefork mpm I > get numbers like ~100 requests/s. > However when I run the same test but now using the worker mpm, this > number drops to almost nothing... > > As I understood it, the worker (or any threaded mpm) should make > mod_dbd/apr_dbd perform better as it enables functionality needing > multi threading (like connection pooling) while prefork limits mod_dbd > to only use a persistent connection strategy. Despite this the prefork > mpm performs better... > > I have tried several different configuration setups without seeing any > great difference. A typical setup is however: 200 max_connections (in > postgresql.conf, the same for both the prefork and worker tests). > Having DBDMax set to 10 while setting ServerLimit to 20 should fully > make mod_dbd utilize all the 200 available connections in Postgres, is > that correct?
One suggestion, you could check with netstat during the test how many
connections to the database are actually opened. Just to get a feel of
how the pool size behaves, and also to double check assumptions.
> Another thing that suggets there is something wrong is that the load
> while running the prefork test is overall high, while running the
> worker test the system load is much lower.
Peter
--
Contact: [EMAIL PROTECTED] (a.k.a. [EMAIL PROTECTED])
#opensuse-mirrors on freenode.net
Info: http://en.opensuse.org/Mirror_Infrastructure
SUSE LINUX Products GmbH
Research & Development
pgpz0Q7k2siHE.pgp
Description: PGP signature
