On 20 Sep 2001, at 17:35, Tobias Giesen wrote:

> my customer wants to know whether to buy a dual pentium server. Does
> this make Interbase 6 or Firebird 1 significantly faster in the
> following situation?
>
> - exclusive Interbase LAN server
> - max. 10 connected users
> - lots of small .gdb database files (each <10MB)
> - each user will connect to 2 or 3 databases at the same time
> - no two users will usually connect to the same databases
> - software not very well optimized for C/S yet,
> it does do a lotta big fetches and stuff

In general the CPU isn't that heavily used in databases, because it
spends 99% of it's time waiting for information to get transfered
to/from the disk subsystem. If your going to spend an extra grand or
so on a duelie board and second CPU, then your better to put that
into extra RAM and beefing up the disk subsystem. How you allocate
that depends partly on the O/S. For example Linux allocates any un-
used memory to the disk cache, so moving from 256MB of RAM to 512MB
of RAM can give you a situation where the most heavily used of those
.gdb files end up entirely in the cache. Of course more memory also
means that more can be allocated to Interbase itself. So you have
some money left, how about replacing those ATA/100 drives with some
Ultra160 SCSI drives, running at 10,000 RPM. This will get the data
into that nice big cache much faster.

If your not running Linux you might still want to do it that way,
boost the RAM and go with faster drives on a wide bus. Before adding
the second CPU.

> I have contemplated merging all these small databases into a big one,
> but for practical purposes I prefer them separate. How much of a
> performance loss does this probably cause? Is there a limit to the
> number of open databases at all?

It probably works out about even, the additional files can actually
be accessed faster, and could possibly end up entirely cached.
Although it does create more for the engine to keep track of. This
is more of a maintenance issue then a performance issue, it can be a
pain trying to keep track of dozens of files, rather then one big
file.

e fact it's not a C/S app is probably the biggest performance
problem, a query that returns 10 rows of 10 fields, will always be
faster then one that returns 10,000,000 rows of 100 fields, given a
database that has 10,000,000 rows of 100 fields. Especially if the
application then has to then figure out the 10 rows it really wants.

Paul

Paul Schmidt,
Tricat Technologies
Email: paul@...
Website: www.tricattechnologies.com