Re: PostgreSQL pre-fork speedup

Поиск
Список
Период
Сортировка
Искать
От
Rod Taylor
Тема
Re: PostgreSQL pre-fork speedup
Дата
в 15:28:59
Msg-id
1083780778.60668.27.camel@jester
Ответ на
Список
Дерево обсуждения
PostgreSQL pre-fork speedup sdv mailer <sdvmailer@yahoo.com>
Re: PostgreSQL pre-fork speedup Paul Ramsey <pramsey@refractions.net>
Re: PostgreSQL pre-fork speedup Tom Lane <tgl@sss.pgh.pa.us>
Re: PostgreSQL pre-fork speedup sdv mailer <sdvmailer@yahoo.com>
Re: PostgreSQL pre-fork speedup Greg Stark <gsstark@mit.edu>
Re: PostgreSQL pre-fork speedup sdv mailer <sdvmailer@yahoo.com>
Re: PostgreSQL pre-fork speedup Andrew Sullivan <ajs@crankycanuck.ca>
Re: PostgreSQL pre-fork speedup sdv mailer <sdvmailer@yahoo.com>
Re: PostgreSQL pre-fork speedup Richard Huxton <dev@archonet.com>
On Wed, 2004-05-05 at 11:57, Greg Stark wrote:
> Rod Taylor  writes:
> 
> > Cutting that count down to 10 idlers in total by having PostgreSQL
> > prefork a specific database would make a significant difference.
> 
> Well it would be 10 for each database. Since as has been pointed out before
> loading the database is most of the delay.
> 
> If that's enough why not just run 10 apache processes instead of 100? 

Because then we would need 10 times as many servers ;)

> I'm assuming the static non-database driven content is already separated onto
> other servers. In which case running 100 apache processes, most of which are
> idle is the source of the problem.

Most of it has been. It's the duty cycle. As stated in another email,
only about 20% of the work a script does is database related -- which
occurs all at one time. Even when all Apache backends are active, a
large number of connections will be idle but were used or will be used
at some point during the generation of that page.

It really is an Apache fault -- but I don't think it can be fixed within Apache itself.



В списке pgsql-hackers по дате отправления
От: Richard Huxton
Дата:
От: Rod Taylor
Дата:
FAQ