Hi folks,

We're currently running Classic, and I'm looking into the possibility of
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?

(4) I am confused by the Firebird Book's description of Superserver and
can't work out how well it will operate on a multicore Linux system (I
gather there are problems on Windows, but we're not planning to use
Windows). Will it use all cores in a sensible fashion?

(5) I understand that the much larger Superserver cache is shared
between connections. But what's not clear to me is whether data in the
cache is shared. For example, if I have two connections each running
through the same 1,500 page table, will that table load itself just once
into 1,500 cache pages which both the connections then access, or will
each connection try to use its own 1,500 pages for its own copy of the
table, for a total of 3,000, from the shared cache? And, when all
connections are closed, will that 1,500 page table remain in the cache
ready for the next connection that's going to need it again in a second
or three?

(6) What is the downside of moving from Classic to Superserver? [It's an
O&M application, with half a dozen or so automatic processes updating
the database as statuses change in the external kit, and a small number
(often one, no more than half a dozen) of user interface connections,
concentrating on (but not entirely limited to) read-only queries.]

Note that Superclassic is not currently an option as we're using 2.1.

Thanks.

--
Tim Ward