Re: PostgreSQL pre-fork speedup
От | Rod Taylor |
---|---|
Тема | Re: PostgreSQL pre-fork speedup |
Дата | |
Msg-id | 1083780412.60668.23.camel@jester обсуждение исходный текст |
Ответ на | Re: PostgreSQL pre-fork speedup (sdv mailer <sdvmailer@yahoo.com>) |
Список | pgsql-hackers |
> Or, you run several seperate Apache webservers. The ones that serve static > content or don't need database connections don't run with the ones that do. > And just like each idle Apache process uses memory and other resources, > each idle PostgreSQL connection does to. So managing the number of Apache Considered that, but it doesn't help much. The duty cycle of any given page is about 20% database, 80% webserver work. So at any given time 80% of the connections to the database will be idle in a best case scenario. If Apache did decent connection pooling or PostgreSQL gave us a hand then a given webserver would need 1/4 of the connections which could be internally shared. Page 1 start Page 1 DB connect Page 1 DB disconnect . . <IDLE persistent connection as work happens> . Page 1 transmit results If we could really disconnect from the database and not suffer high re-connection overhead OR have Apache recognize the connection is unused and allow another Apache backend to use it there would not be a problem. > It all comes down to management, which Apache does a reasonable job of. > If you really believe that you are right and I am wrong, then prove it. I'll > be happy to be shown the error of my thinking (and see an improvement to > PostgreSQL in the process). You wouldn't run into a problem like this on a system with good connection pooling. JBoss comes to mind, once a connection is free it is available to other threads to use. AOL Server is a webserver which demonstrates proper connection pooling. Apache is the problem we're trying to work around. It does everything per backend, rather than having a common pool for the server. That can be fixed by improving PostgreSQL or by doing something (I'm not sure what) with apache.
В списке pgsql-hackers по дате отправления: