Postgre and Web Request

[Kilmer C. de Souza]

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 database,
what happens:
1. With the OS? Will it crash?
2. Will the Postmaster process startup 10.000 diferent processes
at the same time?
3. What about performance? Is there any peformance downgrade?
4. What is the best solution for this problem?
5. How many simultaneos requests may the Postmaster open
withouth decreasing perfomance?


Grettings,
Kilmer Cruz



---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Joshua D. Drake]

Re: Postgre and Web Request

[color=blue]
> (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 database,
> what happens:[/color]

Well the likelyhood of 10,000 users accessing the website at the EXACT
same time is highly unlikely (exponentially so). Remember the web is
stateless so each full request is processed and then the connection is
terminated. This means that connection to postgresql will also be
dropped (unless you use something like connection pooling or persistent
connections).
[color=blue]
> 1. With the OS? Will it crash?[/color]

See above. And actually if you really did have a situation where 10,000
users accessed the site at the exact same time you would need a pretty
large cluster to handle it... regardless of PostgreSQL.
[color=blue]
> 2. Will the Postmaster process startup 10.000 diferent processes
> at the same time?[/color]

See above.
[color=blue]
> 3. What about performance? Is there any peformance downgrade?[/color]

Depends on the machine but that would be the case with any database.

[color=blue]
> 4. What is the best solution for this problem?[/color]

You are asking for a solution to a problem that doesn't really exist at
the database level. You need to spec your hardware requirements overall
and get an firmer understaning of your application requirements. Like I
said, it is highly unlikely that your demands are as high as you mention.

[color=blue]
> 5. How many simultaneos requests may the Postmaster open
> withouth decreasing perfomance?
>[/color]

Depends on the machine... ram, amount of hard disks (not space, quantity
of disks) etc...

Sincerely,

Joshua D. Drake

[color=blue]
>
> Grettings,
> Kilmer Cruz
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend[/color]

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

[Joshua D. Drake]

Re: Postgre and Web Request

[color=blue]
> (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 database,
> what happens:[/color]

Well the likelyhood of 10,000 users accessing the website at the EXACT
same time is highly unlikely (exponentially so). Remember the web is
stateless so each full request is processed and then the connection is
terminated. This means that connection to postgresql will also be
dropped (unless you use something like connection pooling or persistent
connections).
[color=blue]
> 1. With the OS? Will it crash?[/color]

See above. And actually if you really did have a situation where 10,000
users accessed the site at the exact same time you would need a pretty
large cluster to handle it... regardless of PostgreSQL.
[color=blue]
> 2. Will the Postmaster process startup 10.000 diferent processes
> at the same time?[/color]

See above.
[color=blue]
> 3. What about performance? Is there any peformance downgrade?[/color]

Depends on the machine but that would be the case with any database.

[color=blue]
> 4. What is the best solution for this problem?[/color]

You are asking for a solution to a problem that doesn't really exist at
the database level. You need to spec your hardware requirements overall
and get an firmer understaning of your application requirements. Like I
said, it is highly unlikely that your demands are as high as you mention.

[color=blue]
> 5. How many simultaneos requests may the Postmaster open
> withouth decreasing perfomance?
>[/color]

Depends on the machine... ram, amount of hard disks (not space, quantity
of disks) etc...

Sincerely,

Joshua D. Drake

[color=blue]
>
> Grettings,
> Kilmer Cruz
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend[/color]

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

[John Sidney-Woollett]

Re: Postgre and Web Request

Kilmer C. de Souza said:[color=blue]
> 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
> database,
> what happens:
> 1. With the OS? Will it crash?
> 2. Will the Postmaster process startup 10.000 diferent
> processes
> at the same time?
> 3. What about performance? Is there any peformance downgrade?
> 4. What is the best solution for this problem?
> 5. How many simultaneos requests may the Postmaster open
> withouth decreasing perfomance?[/color]

Depending on your web development environment (java, php, .NET) etc, you
should be able to use some mechanism that will provide a pool of
connections to the database. Each request does not open a new connection
(and then release it), but insteads gets a connection from the pool to
use, and returns it back to the pool when done.

In a recent java web website (I was involved with) which was serving on
average 3 page requests per second, we only used a pool of 8 connections.
Also some pages requests required multiple queries to generate all the
data prior to rendering the page. I can't remember the number of
concurrent user. But you get the idea that even a small pool can service
lots of traffic (if your SQL queries are nicely optimized).

I'm afraid I cannot answer your specific questions on how many
simulatenous and active connections postgres will support; but I suspect
that it is limited by memory and hardware. Perhaps someone else can help.

John Sidney-Woollett

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[John Sidney-Woollett]

Re: Postgre and Web Request

Kilmer C. de Souza said:[color=blue]
> 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
> database,
> what happens:
> 1. With the OS? Will it crash?
> 2. Will the Postmaster process startup 10.000 diferent
> processes
> at the same time?
> 3. What about performance? Is there any peformance downgrade?
> 4. What is the best solution for this problem?
> 5. How many simultaneos requests may the Postmaster open
> withouth decreasing perfomance?[/color]

Depending on your web development environment (java, php, .NET) etc, you
should be able to use some mechanism that will provide a pool of
connections to the database. Each request does not open a new connection
(and then release it), but insteads gets a connection from the pool to
use, and returns it back to the pool when done.

In a recent java web website (I was involved with) which was serving on
average 3 page requests per second, we only used a pool of 8 connections.
Also some pages requests required multiple queries to generate all the
data prior to rendering the page. I can't remember the number of
concurrent user. But you get the idea that even a small pool can service
lots of traffic (if your SQL queries are nicely optimized).

I'm afraid I cannot answer your specific questions on how many
simulatenous and active connections postgres will support; but I suspect
that it is limited by memory and hardware. Perhaps someone else can help.

John Sidney-Woollett

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Bill Moran]

Re: Postgre and Web Request

Kilmer C. de Souza wrote:[color=blue]
> 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)[/color]

You're right. It will start a seperate process for each connection.
[color=blue]
> If all users try to access, through WEB, at same time the database,
> what happens:
> 1. With the OS? Will it crash?[/color]

No. At least, no self-respecting posix system will crash. None that I
know of, anyway.
[color=blue]
> 2. Will the Postmaster process startup 10.000 diferent processes
> at the same time?[/color]

No.
[color=blue]
> 3. What about performance? Is there any peformance downgrade?[/color]

Yes. At that load you'll almost definately see a massive performance problem.
[color=blue]
> 4. What is the best solution for this problem?[/color]

You're presenting an unrealistic scenerio, and I'll explain why in a moment.
[color=blue]
> 5. How many simultaneos requests may the Postmaster open
> withouth decreasing perfomance?[/color]

Depends on the hardware.

Fact is, the scenerio of "10,000 users access at the same time" will almost
never happen ... especially not through the web. That would be one
tremendiously popular website.

First off, any web browser I've ever seen puts a cap on the number of
simultaneous connections. Usually around a few hundred. Let's say
your web server has a cap of 200 simultaneous connections (not unusual)
and you get 10,000 requests at exactly the same moment (unlikely in any
case) Your web browser will immediately start servicing 200 of the
requests. The remaining 9,800 will be queued to be handled as soon as
one of the 200 is complete. Since web requests generally finish fairly
quickly, you'll actually see the 10,000 get serviced in short order,
although not as quickly as the 9,999th surfer would like, I'm sure.

However, it's likely that your operating system won't be able to queue
that big of a backlog, and quite a few of those attempts will return
an error that the server is too busy.

On the flip side, let's do some numbers, if you're getting 10,000 request
per second, that's 864,000,000 hits per day ... are you actually expecting
that amount of traffic? 10,000 per second doesn't even qualify as "at
the same time".

Evaluating your needs would better be accomplished by calculating the max
load over a fixed period of time, determining how long an average request
takes, and using that to figure out the number of processes that will
need to be running. For example:

If I figure that between 9:00 and 11:00 am is the busiest it will get, and
I'll get approximate 100,000 hits, that's about 14 hits per second, and if
each request takes about 3 seconds, I can figure that I'll have 42 requests
active during any one second of that time. Not too bad of a load.

To be safe, I double that, and set Apache's max processes to 100, then
set Postgres max processes to the same. Then I spec out hardware that
can handle the load and I'm off and running.

--
Bill Moran
Potential Technologies

http://www.potentialtech.com

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Bill Moran]

Re: Postgre and Web Request

Kilmer C. de Souza wrote:[color=blue]
> 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)[/color]

You're right. It will start a seperate process for each connection.
[color=blue]
> If all users try to access, through WEB, at same time the database,
> what happens:
> 1. With the OS? Will it crash?[/color]

No. At least, no self-respecting posix system will crash. None that I
know of, anyway.
[color=blue]
> 2. Will the Postmaster process startup 10.000 diferent processes
> at the same time?[/color]

No.
[color=blue]
> 3. What about performance? Is there any peformance downgrade?[/color]

Yes. At that load you'll almost definately see a massive performance problem.
[color=blue]
> 4. What is the best solution for this problem?[/color]

You're presenting an unrealistic scenerio, and I'll explain why in a moment.
[color=blue]
> 5. How many simultaneos requests may the Postmaster open
> withouth decreasing perfomance?[/color]

Depends on the hardware.

Fact is, the scenerio of "10,000 users access at the same time" will almost
never happen ... especially not through the web. That would be one
tremendiously popular website.

First off, any web browser I've ever seen puts a cap on the number of
simultaneous connections. Usually around a few hundred. Let's say
your web server has a cap of 200 simultaneous connections (not unusual)
and you get 10,000 requests at exactly the same moment (unlikely in any
case) Your web browser will immediately start servicing 200 of the
requests. The remaining 9,800 will be queued to be handled as soon as
one of the 200 is complete. Since web requests generally finish fairly
quickly, you'll actually see the 10,000 get serviced in short order,
although not as quickly as the 9,999th surfer would like, I'm sure.

However, it's likely that your operating system won't be able to queue
that big of a backlog, and quite a few of those attempts will return
an error that the server is too busy.

On the flip side, let's do some numbers, if you're getting 10,000 request
per second, that's 864,000,000 hits per day ... are you actually expecting
that amount of traffic? 10,000 per second doesn't even qualify as "at
the same time".

Evaluating your needs would better be accomplished by calculating the max
load over a fixed period of time, determining how long an average request
takes, and using that to figure out the number of processes that will
need to be running. For example:

If I figure that between 9:00 and 11:00 am is the busiest it will get, and
I'll get approximate 100,000 hits, that's about 14 hits per second, and if
each request takes about 3 seconds, I can figure that I'll have 42 requests
active during any one second of that time. Not too bad of a load.

To be safe, I double that, and set Apache's max processes to 100, then
set Postgres max processes to the same. Then I spec out hardware that
can handle the load and I'm off and running.

--
Bill Moran
Potential Technologies

http://www.potentialtech.com

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Kilmer C. de Souza]

Re: Postgre and Web Request

Oww ... sorry man ...
I make a mistake ... there are 10.000 users and 1.000 from 10.000 try to
access at the same time the database.
Can you help me again with this condition?

Grettings
Kilmer Cruz

----- Original Message -----
From: "Joshua D. Drake" <jd@commandprom pt.com>
To: "Kilmer C. de Souza" <listas@miti.co m.br>
Cc: <pgsql-general@postgre sql.org>
Sent: Wednesday, April 28, 2004 3:56 PM
Subject: Re: [GENERAL] Postgre and Web Request

[color=blue]
>[color=green]
> > (the manual stated the following: there is a main[/color][/color]
process[color=blue][color=green]
> > called postmaster. It starts new processes to each different request and
> > each different user ... I dont understand very well ... please correct[/color][/color]
me[color=blue][color=green]
> > if I`m wrong)
> > If all users try to access, through WEB, at same time the[/color][/color]
database,[color=blue][color=green]
> > what happens:[/color]
>
> Well the likelyhood of 10,000 users accessing the website at the EXACT
> same time is highly unlikely (exponentially so). Remember the web is
> stateless so each full request is processed and then the connection is
> terminated. This means that connection to postgresql will also be
> dropped (unless you use something like connection pooling or persistent
> connections).
>[color=green]
> > 1. With the OS? Will it crash?[/color]
>
> See above. And actually if you really did have a situation where 10,000
> users accessed the site at the exact same time you would need a pretty
> large cluster to handle it... regardless of PostgreSQL.
>[color=green]
> > 2. Will the Postmaster process startup 10.000 diferent[/color][/color]
processes[color=blue][color=green]
> > at the same time?[/color]
>
> See above.
>[color=green]
> > 3. What about performance? Is there any peformance[/color][/color]
downgrade?[color=blue]
>
> Depends on the machine but that would be the case with any database.
>
>[color=green]
> > 4. What is the best solution for this problem?[/color]
>
> You are asking for a solution to a problem that doesn't really exist at
> the database level. You need to spec your hardware requirements overall
> and get an firmer understaning of your application requirements. Like I
> said, it is highly unlikely that your demands are as high as you mention.
>
>[color=green]
> > 5. How many simultaneos requests may the Postmaster open
> > withouth decreasing perfomance?
> >[/color]
>
> Depends on the machine... ram, amount of hard disks (not space, quantity
> of disks) etc...
>
> Sincerely,
>
> Joshua D. Drake
>
>[color=green]
> >
> > Grettings,
> > Kilmer Cruz
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 8: explain analyze is your friend[/color]
>
>[/color]



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

[Kilmer C. de Souza]

Re: Postgre and Web Request

Oww ... sorry man ...
I make a mistake ... there are 10.000 users and 1.000 from 10.000 try to
access at the same time the database.
Can you help me again with this condition?

Grettings
Kilmer Cruz

----- Original Message -----
From: "Joshua D. Drake" <jd@commandprom pt.com>
To: "Kilmer C. de Souza" <listas@miti.co m.br>
Cc: <pgsql-general@postgre sql.org>
Sent: Wednesday, April 28, 2004 3:56 PM
Subject: Re: [GENERAL] Postgre and Web Request

[color=blue]
>[color=green]
> > (the manual stated the following: there is a main[/color][/color]
process[color=blue][color=green]
> > called postmaster. It starts new processes to each different request and
> > each different user ... I dont understand very well ... please correct[/color][/color]
me[color=blue][color=green]
> > if I`m wrong)
> > If all users try to access, through WEB, at same time the[/color][/color]
database,[color=blue][color=green]
> > what happens:[/color]
>
> Well the likelyhood of 10,000 users accessing the website at the EXACT
> same time is highly unlikely (exponentially so). Remember the web is
> stateless so each full request is processed and then the connection is
> terminated. This means that connection to postgresql will also be
> dropped (unless you use something like connection pooling or persistent
> connections).
>[color=green]
> > 1. With the OS? Will it crash?[/color]
>
> See above. And actually if you really did have a situation where 10,000
> users accessed the site at the exact same time you would need a pretty
> large cluster to handle it... regardless of PostgreSQL.
>[color=green]
> > 2. Will the Postmaster process startup 10.000 diferent[/color][/color]
processes[color=blue][color=green]
> > at the same time?[/color]
>
> See above.
>[color=green]
> > 3. What about performance? Is there any peformance[/color][/color]
downgrade?[color=blue]
>
> Depends on the machine but that would be the case with any database.
>
>[color=green]
> > 4. What is the best solution for this problem?[/color]
>
> You are asking for a solution to a problem that doesn't really exist at
> the database level. You need to spec your hardware requirements overall
> and get an firmer understaning of your application requirements. Like I
> said, it is highly unlikely that your demands are as high as you mention.
>
>[color=green]
> > 5. How many simultaneos requests may the Postmaster open
> > withouth decreasing perfomance?
> >[/color]
>
> Depends on the machine... ram, amount of hard disks (not space, quantity
> of disks) etc...
>
> Sincerely,
>
> Joshua D. Drake
>
>[color=green]
> >
> > Grettings,
> > Kilmer Cruz
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 8: explain analyze is your friend[/color]
>
>[/color]



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

[Mike Nolan]

Re: Postgre and Web Request

> I make a mistake ... there are 10.000 users and 1.000 from 10.000 try to[color=blue]
> access at the same time the database.[/color]

I have problems with your numbers. Even if you have 10,000 users who
are ALL online at the same time, in any reasonable period of time (say
60 seconds), how many of them would initiate a request?

In most online applications, 95% OR MORE of all time is spent waiting
for the user to do something. Web-based applications seem to fit that
rule fairly well, because nothing happens at the server end for any
given user until a 'submit' button is pressed.

Consider, for example, a simple name-and-address entry form. A really
fast typist can probably fill out 60-70 of them in an hour. That
means each user is submitting a request every 50-60 seconds. Thus
if there were 10,000 users doing this FULL TIME, they would generate
something under 200 requests/second.

In practice, I wouldn't expect to see more than 50-75 requests/second,
and it shouldn't be too hard to design a hardware configuration capable
of supporting that, disk speed and memory size are likely to be the
major bottleneck points.

I don't know if anyone has ever set up a queuing theory model for a
PostgreSQL+Apac he environment, there are probably too many individual
tuning factors (not to mention application specific factors) to make
a generalizable model practical.
--
Mike Nolan

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Mike Nolan]

Re: Postgre and Web Request

> I make a mistake ... there are 10.000 users and 1.000 from 10.000 try to[color=blue]
> access at the same time the database.[/color]

I have problems with your numbers. Even if you have 10,000 users who
are ALL online at the same time, in any reasonable period of time (say
60 seconds), how many of them would initiate a request?

In most online applications, 95% OR MORE of all time is spent waiting
for the user to do something. Web-based applications seem to fit that
rule fairly well, because nothing happens at the server end for any
given user until a 'submit' button is pressed.

Consider, for example, a simple name-and-address entry form. A really
fast typist can probably fill out 60-70 of them in an hour. That
means each user is submitting a request every 50-60 seconds. Thus
if there were 10,000 users doing this FULL TIME, they would generate
something under 200 requests/second.

In practice, I wouldn't expect to see more than 50-75 requests/second,
and it shouldn't be too hard to design a hardware configuration capable
of supporting that, disk speed and memory size are likely to be the
major bottleneck points.

I don't know if anyone has ever set up a queuing theory model for a
PostgreSQL+Apac he environment, there are probably too many individual
tuning factors (not to mention application specific factors) to make
a generalizable model practical.
--
Mike Nolan

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Chris Browne]

Re: Postgre and Web Request

listas@miti.com .br ("Kilmer C. de Souza") writes:[color=blue]
> Oww ... sorry man ...
> I make a mistake ... there are 10.000 users and 1.000 from 10.000 try to
> access at the same time the database.
> Can you help me again with this condition?[/color]

The issues don't really change. Opening 1000 concurrent connections
means spawning 1K PostgreSQL processes, which will reserve a pile of
memory, and cause a pretty severe performance problem.

It is _vital_ that your application uses some form of "connection
pooling" so that it can share 50-100 connections across the requests
rather than opening 1K connections.

How that is done will depend on your favored web application
framework. Most frameworks have some notion of a "connection pool,"
so this certainly shouldn't need to be a crippling problem.
--
(format nil "~S@~S" "cbbrowne" "ntlug.org" )

http://cbbrowne.com/info/lsf.html

Rules of the Evil Overlord #75. "I will instruct my Legions of Terror
to attack the hero en masse, instead of standing around waiting while
members break off and attack one or two at a time."
<http://www.eviloverlor d.com/>

[Chris Browne]

Re: Postgre and Web Request

listas@miti.com .br ("Kilmer C. de Souza") writes:[color=blue]
> Oww ... sorry man ...
> I make a mistake ... there are 10.000 users and 1.000 from 10.000 try to
> access at the same time the database.
> Can you help me again with this condition?[/color]

The issues don't really change. Opening 1000 concurrent connections
means spawning 1K PostgreSQL processes, which will reserve a pile of
memory, and cause a pretty severe performance problem.

It is _vital_ that your application uses some form of "connection
pooling" so that it can share 50-100 connections across the requests
rather than opening 1K connections.

How that is done will depend on your favored web application
framework. Most frameworks have some notion of a "connection pool,"
so this certainly shouldn't need to be a crippling problem.
--
(format nil "~S@~S" "cbbrowne" "ntlug.org" )

http://cbbrowne.com/info/lsf.html

Rules of the Evil Overlord #75. "I will instruct my Legions of Terror
to attack the hero en masse, instead of standing around waiting while
members break off and attack one or two at a time."
<http://www.eviloverlor d.com/>

[Paul Tillotson]

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
[color=blue]
>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?
>
>[/color]



---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Paul Tillotson]

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
[color=blue]
>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?
>
>[/color]



---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings