From: | Vivek Khera <khera(at)kcilink(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Hardware recommendations to scale to silly load |
Date: | 2003-09-02 16:08:15 |
Message-ID: | x7d6ejb2c0.fsf@yertle.int.kciLink.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
>>>>> "MC" == Matt Clark <matt(at)ymogen(dot)net> writes:
MC> And concurrency is very high, because it's a web app, and each
MC> httpd has one connection to PG, and there can be hundreds of
MC> active httpd processes. Some kind of connection pooling scheme
MC> might be in order when there are that many active clients. Any
One thing you really should do (don't know if you already do it...) is
have your web split into a front-end proxy and a back-end application
server. There are lots of docs on how to do this for mod_perl, but it
can apply to just about any backend technology that is pooling the
connections.
With a setup like this, my front-end web server typically has about
100 to 150 connections, and the backend doing the dynamic work (and
accessing the database) has peaked at 60 or so. Usually the backend
numbers at about 25.
The front-end small processes get to deal with your dialup customers
trickling down the data since it buffers your backend for you.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera(at)kciLink(dot)com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-09-02 16:58:46 | Re: C++ and a stored procudre |
Previous Message | Vivek Khera | 2003-09-02 16:01:16 | Re: Hardware recommendations to scale to silly load |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2003-09-02 16:14:34 | Re: opinion on RAID choice |
Previous Message | Vivek Khera | 2003-09-02 16:01:16 | Re: Hardware recommendations to scale to silly load |