| Subject | Re: Super Server/Classic Server install |
|---|---|
| Author | Adam |
| Post date | 2006-07-27T23:21:04Z |
--- In firebird-support@yahoogroups.com, "yuppski" <yuppski@...> wrote:
less than a minute of downtime to switch between architectures if you
decide you made the wrong decision.
Classic server is more appropriate for multiple databases, although we
used Superserver for several years on a machine hosting 30 odd databases.
I would recommend classic because:
* A corrupt database will ruin everyones connection under Superserver.
If for whatever reason you end up with a corrupt record version in a
database (extremely rare), the engine panics and is restarted, closing
all active connections. Under classic, this only affects the
connection that was unlucky enough to stumble upon that corrupted
record version, not someone accessing an unrelated database.
* 32 bit limitations:
If you have enough users in enough databases, the combined cache size
on Superserver may see the process size reach 2GB at which time the
process will not restart but just hang. With Classic, the 2GB
limitation is per connection, so it is a non issue.
* SMP support
If you have more than one physical processor in the box, classic
server allows multiple queries to be processed simultaneously, whereas
Superserver will be stuck on one (best case) or be continuously
switched between processes (worst case).
In practice, Classic server tends to take between 7 and 10MB per
connection as a starting point, though this can increase if you do a
lot of sorting. The main thing to be careful of is that you have
enough physical RAM to accommodate the peak number of connections. If
not, you need to reduce the size of the cache so it does fit in RAM.
Superserver can perform better if you have each connection doing
similar queries, as the shared cache (that classic does not have)
tends to come into play, so it is a matter of adding up the benefits
and drawbacks of each architecture and choosing the one that best fits
your needs.
Adam
>Either architecture is capable of doing what you require, and it takes
> Hi All
>
> Would the Super Server install be more approriate, performace (plus
> any other) reasons, for muliple users connecting to multiple database
> than the Classic Server install ? (on the Server)
>
> For the client to connect to the server via an Alias what would be
> the
> appropriate install ?
>
> Sorry if I've missed any relevant information.
>
less than a minute of downtime to switch between architectures if you
decide you made the wrong decision.
Classic server is more appropriate for multiple databases, although we
used Superserver for several years on a machine hosting 30 odd databases.
I would recommend classic because:
* A corrupt database will ruin everyones connection under Superserver.
If for whatever reason you end up with a corrupt record version in a
database (extremely rare), the engine panics and is restarted, closing
all active connections. Under classic, this only affects the
connection that was unlucky enough to stumble upon that corrupted
record version, not someone accessing an unrelated database.
* 32 bit limitations:
If you have enough users in enough databases, the combined cache size
on Superserver may see the process size reach 2GB at which time the
process will not restart but just hang. With Classic, the 2GB
limitation is per connection, so it is a non issue.
* SMP support
If you have more than one physical processor in the box, classic
server allows multiple queries to be processed simultaneously, whereas
Superserver will be stuck on one (best case) or be continuously
switched between processes (worst case).
In practice, Classic server tends to take between 7 and 10MB per
connection as a starting point, though this can increase if you do a
lot of sorting. The main thing to be careful of is that you have
enough physical RAM to accommodate the peak number of connections. If
not, you need to reduce the size of the cache so it does fit in RAM.
Superserver can perform better if you have each connection doing
similar queries, as the shared cache (that classic does not have)
tends to come into play, so it is a matter of adding up the benefits
and drawbacks of each architecture and choosing the one that best fits
your needs.
Adam