httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Poeml <>
Subject Re: mod_dbd issues in worker vs prefork mpm
Date Fri, 07 Nov 2008 14:46:05 GMT

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.

Contact: (a.k.a.
         #opensuse-mirrors on
SUSE LINUX Products GmbH
Research & Development

View raw message