Subject | RE: [firebird-support] Classic vs Superserver |
---|---|
Author | Leyne, Sean |
Post date | 2013-08-29T14:57:05Z |
Tim,
Classic does not provide the fastest performance, but it does provide the most consistent multi-connection performance. It is currently (v3 will be changing this) the only engine which truly scales across CPUs.
Garbage Collection is performed actively, but if you have good transaction management, the real overhead is not that bad. The biggest cost of Garbage Collection is that it generates disk writes, which will need to go to disk, which is a slow process. A good disk controller cache with protected write-back cache will eliminate that cost.
Cache is and isn't a limitation, yes the engine will need to go to the OS for pages not in FB cache. With a reasonable amount of RAM in your server, however, the OS itself will have most 'hot' database pages cached, so you will not actually be going to disk to get the data. Here the faster the media, the lower the cost of the reads will be.
Sean
> We're currently running Classic, and I'm looking into the possibility ofYes and no. ;-]
> switching to Superserver for the following reasons:
>
> (1) Garbage collection - we sometimes get queries, that normally complete in
> reasonable time, taking many times as long, and one possible explanation is
> garbage collection. We understand that Superserver has a background GC
> thread, so the chances of a two second user operation being randomly
> delayed by minutes can be reduced or eliminated.
>
> (2) Cache size. With frequent operations on a particular table occupying
> around 1,500 pages the cache size of 150 that we're currently using is
> believed to limit performance.
>
> So some questions:
>
> (3) Do these motivations make sense?
Classic does not provide the fastest performance, but it does provide the most consistent multi-connection performance. It is currently (v3 will be changing this) the only engine which truly scales across CPUs.
Garbage Collection is performed actively, but if you have good transaction management, the real overhead is not that bad. The biggest cost of Garbage Collection is that it generates disk writes, which will need to go to disk, which is a slow process. A good disk controller cache with protected write-back cache will eliminate that cost.
Cache is and isn't a limitation, yes the engine will need to go to the OS for pages not in FB cache. With a reasonable amount of RAM in your server, however, the OS itself will have most 'hot' database pages cached, so you will not actually be going to disk to get the data. Here the faster the media, the lower the cost of the reads will be.
Sean