| Subject | Re: [firebird-support] Multiple Connections |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-07-17T08:17:29Z |
At 03:48 AM 17/07/2005 +0000, you wrote:
depends on several factors, including
1) the spread of operations loading (all writing; some heavy writes, some
light? mostly reading, etc.)
2) whether you are using Classic or Superserver...Classic allows you to
make use of multiple CPUs so if 1) is CPU-intensive, it could be worth
considering, if you have a lot of resource available...Superserver is more
efficient with caching so it has advantages when you have a lot of users
hitting the same records concurrently and/or repeatedly
3) How efficiently your application code manages transactions. It's
really worth making the effort to understand how concurrency and the
multi-generational architecture work, to have it working for you and not
against you.
4) Hardware and system resources are really important. You want the DB
server running on a machine that has no other jobs to do. You do NOT want
it on a machine that depends on a graphical interface to interact with the
adminstrator. Linux, sans X, gives you superior bang-for-buck at the cheap
end. You want plenty of RAM.
support connection pooling.
system if there is a lot of interactive work going on. 100 concurrent
users isn't overly much on a well-resourced server but why drain the system
unnecessarily? n-tier will give you optimal use of both machine and
network resources.
This question doesn't have a five-minute answer - I hope you didn't expect
it would. Some sites are running thousands of concurrent connections
smoothly and efficiently, yet this support list does, regrettably,
sometimes see scenarios that struggle to cope with 10 users. It's the same
software, so go figure.
./heLen
>Hi,The theoretical limit is 1024 concurrent connections; the practical limit
>How many users can FB support concurrently..
depends on several factors, including
1) the spread of operations loading (all writing; some heavy writes, some
light? mostly reading, etc.)
2) whether you are using Classic or Superserver...Classic allows you to
make use of multiple CPUs so if 1) is CPU-intensive, it could be worth
considering, if you have a lot of resource available...Superserver is more
efficient with caching so it has advantages when you have a lot of users
hitting the same records concurrently and/or repeatedly
3) How efficiently your application code manages transactions. It's
really worth making the effort to understand how concurrency and the
multi-generational architecture work, to have it working for you and not
against you.
4) Hardware and system resources are really important. You want the DB
server running on a machine that has no other jobs to do. You do NOT want
it on a machine that depends on a graphical interface to interact with the
adminstrator. Linux, sans X, gives you superior bang-for-buck at the cheap
end. You want plenty of RAM.
>does it supports connection pooling?Connecting is what clients do. Most of the client application interfaces
support connection pooling.
>In our application on average there will be 50-60 users usingThen 5) you should seriously consider a multi-tier architecture for your
>it simultaneous ly..and in some exceptional cases 80-100
system if there is a lot of interactive work going on. 100 concurrent
users isn't overly much on a well-resourced server but why drain the system
unnecessarily? n-tier will give you optimal use of both machine and
network resources.
This question doesn't have a five-minute answer - I hope you didn't expect
it would. Some sites are running thousands of concurrent connections
smoothly and efficiently, yet this support list does, regrettably,
sometimes see scenarios that struggle to cope with 10 users. It's the same
software, so go figure.
./heLen