Scaling / Number of simultanous connections

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Scaling / Number of simultanous connections

Nico Callewaert-4
Hi,

I'm about to start porting a Firebird DB to Postgres. Next thing will be upgrading all customers. Most of our customers have around 30 users or less. We have a few 'bigger' customers that maybe have 50 users or a bit more still. The application is a Delphi application that is in fact a 'fat' client that uses a permanent connection to the DB. I've read that Postgres uses 1 process per user. So that means 30-50 processes at the same time. 

I have 2 questions about this
- I guess this situation is not really a heavy workload? Or is it?
- And is it correct that a single process cannot access multiple CPU cores, so things are not multi threaded? I guess MySQL used that argument somewhere, but I'm not sure, forgive me if I'm mistaken.

The whole thing boils down to this question: Am I save with 30-50 simultanous users for speed and scaling?

Thanks a lot in advance!
Best regards, Nico
Reply | Threaded
Open this post in threaded view
|

Re: Scaling / Number of simultanous connections

Andreas Kretschmer-3


Am 07.02.19 um 18:43 schrieb Nico Callewaert:

> Hi,
>
> I'm about to start porting a Firebird DB to Postgres. Next thing will
> be upgrading all customers. Most of our customers have around 30 users
> or less. We have a few 'bigger' customers that maybe have 50 users or
> a bit more still. The application is a Delphi application that is in
> fact a 'fat' client that uses a permanent connection to the DB. I've
> read that Postgres uses 1 process per user. So that means 30-50
> processes at the same time.
>
> I have 2 questions about this
> - I guess this situation is not really a heavy workload? Or is it?

not really, assuming not all connections are active the same time.

> - And is it correct that a single process cannot access multiple CPU
> cores, so things are not multi threaded? I guess MySQL used that
> argument somewhere, but I'm not sure, forgive me if I'm mistaken.

yes and no, since 9.6 we can use multiple cores for one query, using
multiple processes.


>
> The whole thing boils down to this question: Am I save with 30-50
> simultanous users for speed and scaling?
>

most likely yes, on modern hardware.


Regards, Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com


Reply | Threaded
Open this post in threaded view
|

Re: Scaling / Number of simultanous connections

Dwayne A
You could also look at pgbouncer for connection pooling.


Cheers,
Dwayne


On Thu., Feb. 7, 2019, 9:57 a.m. Andreas Kretschmer, <[hidden email]> wrote:


Am 07.02.19 um 18:43 schrieb Nico Callewaert:
> Hi,
>
> I'm about to start porting a Firebird DB to Postgres. Next thing will
> be upgrading all customers. Most of our customers have around 30 users
> or less. We have a few 'bigger' customers that maybe have 50 users or
> a bit more still. The application is a Delphi application that is in
> fact a 'fat' client that uses a permanent connection to the DB. I've
> read that Postgres uses 1 process per user. So that means 30-50
> processes at the same time.
>
> I have 2 questions about this
> - I guess this situation is not really a heavy workload? Or is it?

not really, assuming not all connections are active the same time.

> - And is it correct that a single process cannot access multiple CPU
> cores, so things are not multi threaded? I guess MySQL used that
> argument somewhere, but I'm not sure, forgive me if I'm mistaken.

yes and no, since 9.6 we can use multiple cores for one query, using
multiple processes.


>
> The whole thing boils down to this question: Am I save with 30-50
> simultanous users for speed and scaling?
>

most likely yes, on modern hardware.


Regards, Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com


Reply | Threaded
Open this post in threaded view
|

Re: Scaling / Number of simultanous connections

Nico Callewaert-4
Hi,

Thanks to everybody for the answers. Indeed, not all the time there is traffic on all those connections.

Thanks, best regards, Nico

Op ma 11 feb. 2019 om 12:40 schreef Nico Callewaert <[hidden email]>:
Hi,

Thanks to everybody for the answers. Indeed, not all the time there is traffic on all those connections.

Thanks, best regards, Nico

Op vr 8 feb. 2019 om 22:24 schreef Dwayne A <[hidden email]>:
You could also look at pgbouncer for connection pooling.


Cheers,
Dwayne


On Thu., Feb. 7, 2019, 9:57 a.m. Andreas Kretschmer, <[hidden email]> wrote:


Am 07.02.19 um 18:43 schrieb Nico Callewaert:
> Hi,
>
> I'm about to start porting a Firebird DB to Postgres. Next thing will
> be upgrading all customers. Most of our customers have around 30 users
> or less. We have a few 'bigger' customers that maybe have 50 users or
> a bit more still. The application is a Delphi application that is in
> fact a 'fat' client that uses a permanent connection to the DB. I've
> read that Postgres uses 1 process per user. So that means 30-50
> processes at the same time.
>
> I have 2 questions about this
> - I guess this situation is not really a heavy workload? Or is it?

not really, assuming not all connections are active the same time.

> - And is it correct that a single process cannot access multiple CPU
> cores, so things are not multi threaded? I guess MySQL used that
> argument somewhere, but I'm not sure, forgive me if I'm mistaken.

yes and no, since 9.6 we can use multiple cores for one query, using
multiple processes.


>
> The whole thing boils down to this question: Am I save with 30-50
> simultanous users for speed and scaling?
>

most likely yes, on modern hardware.


Regards, Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com