Re: Postgre and Web Request

Kilmer:

Rhetorical question: I read in the documentation for Apache and IIS
that they create a new process or thread for each user. Can your
hardware handle 10,000 simultaneous threads? : ) Probably not, and
there is a reason that it doesn't need to.....

If your web setup uses connection pooling, ask the person who is setting
that up for a better explanation. If not, then I'll assume that you
won't use connection pooling.

If you don't use connection pooling, a new process is created for each
web hit, but that process ends as soon as the web hit is finished.

Thus, the number of users you have isn't the number to look at. What
matters is how many hits per second you get at your peak. We get about
2 hits per second. Assuming that each hit takes 1/10 of a second, then
that means that (on average) for 2/10 of a second, the database is doing
work, and for 8/10 of a second, it is idle, with NO processes running
other than the postmaster. Even if all your users are online at the
same time, then the hit rate is what matters.

Get out your web logs and see how much traffic you get. As a rough
rule, unless you have something more than 10 hits per second or your
web-app does something unusual, then you don't need to worry about any
of this stuff at all.

Paul Tillotson

>Hi,
>
> I am a new user of PostgreSQL and there are some questions about its
>performance in a scenario with a high requisition rate
>
> Lets picture an imaginary scenario:
> In my system (Debian Linux), there are 200.000.000 records on the
>database, and a total number of 10.000 diferent users.
> (the manual stated the following: there is a main process
>called postmaster. It starts new processes to each different request and
>each different user ... I dont understand very well ... please correct me
>if I`m wrong)
> If all users try to access, through WEB, at same time the databasewhat happens:
> 1. With the OS? Will it crash?
>
>