What kind of workstation

What kind of workstation

Post by Eric ten W » Thu, 15 Mar 2007 05:25:01


We want to run IB 2007 with 100 concurrent users.

Can somebody recommend me the confirguration i need?

- processor
- memory
- disks (raid?)


What kind of workstation

Post by Wayne Nidd » Thu, 15 Mar 2007 05:41:40

Not really enough information. What kind of work will these users be doing,
mostly reading or lots of updating? How busy - what volume of transactions
would you expect during both normal and peak usage? How much data in key

It would be easy to say you should simply get the fastest, biggest
(memory/disk) machine you can afford, but depending on the above, you might
be able to do perfectly fine on substantially less.

Raid is probably a good idea in any case.

Wayne Niddery - Winwright, Inc (www.winwright.ca)
"A man is likely to mind his own business when it is worth minding,
when it is not, he takes his mind off his own meaningless affairs by
minding other people's business." - Eric Hoffer


What kind of workstation

Post by Dan Palle » Thu, 15 Mar 2007 05:42:49

IB can take advantage of multiple processors. Whether this will benefit you
or not depends on a lot of factors. I'd go with a system that allows you to
upgrade processors if possible and get, say, half of the total. For a two
processor server, go with one dual-core CPU. You can add a 2nd one later
on, for a total of 4 cores.

Current IB versions can only use up to 2 GB of memory, unless you use
multiple instances. If the server is primarily for Interbase, then 4 GB
should be plenty.

Definitely put the database files on their own volume. Try to create a
separate volume for the logs as well.


What kind of workstation

Post by Eric ten W » Thu, 15 Mar 2007 05:58:15

Hi Wayne,

The problem we have now is when the user creates reports using Delphi +
These reports use views, and views are not that smart.

Now running on IB 6.02, all works fine, only views are slow.


"Wayne Niddery [TeamB]" < XXXX@XXXXX.COM > schreef in bericht

What kind of workstation

Post by Bill Tod » Thu, 15 Mar 2007 07:29:20

How big is the database?

Can you show us a SELECT on a view that is slow along with the
definition of the view and the metadata for the tables in volved.

Also show us the plan for the SELECT on the view.

Throwing hardware at performance problems frequently does not fix them
or has less than the desired impact. If you have performance problems
you need to find out why the operation is slow. Then you can decide if
you need more hardware and what kind or if something else will provide
better performance.

Bill Todd (TeamB)

What kind of workstation

Post by Wayne Nidd » Thu, 15 Mar 2007 13:05:38

Views should generally be as smart as the underlying tables - the indexes
should be used the same way for the view as if you executed the same query
directly, with the difference that it is already prepared.

However, whether this is actually the problem or not, IB6 is now almost 8
years old. Interbase has changed *a lot* since then, there's really no

Wayne Niddery - Winwright, Inc (www.winwright.ca)
"True peace is not the absence of tension, but the presence of
justice." - Martin Luther King, Jr.

What kind of workstation

Post by Will » Thu, 15 Mar 2007 15:07:17

Other people are advising on software so...

I am currently working on a server with Novel OES2 (Suse Linux 9 SLES +
OES) -- It is reasonable performance -- but -- knowing what I know now
it would be a RAID 5 SCSI system -- not SATA. I also would have
purchased a router that allowed me to "Bond" channels to improve
throughput to/from the server.

One suggestion
AMD 64 -- X2 I use ASUS motherboards)
4GB Memory
500GB to 1TB disk SCSI RAID Array (3 to 5 drives)
(OR a 4-8 drive SATA Array with careful choice of hard drives)
(Note that 25% of RAID array is for "redundancy")
High Speed Ethernet (2 X 1GB Channels bonded at Router or System)
or 10GB Ethernet if you are serving graphics data
Backup -- use Acronis (or similar) and 500GB disk drives externally on
SATA or USB -- faster than tape
UPS of sufficient capacity to keep system on 1/2 hour or more.

We had to custom build our workstation and server products to serve
mining and mapping purposes. (ASUS A8R MV2 Motherboards -- which have
been stable under Linux and Windows.)

Bigger hard drives are generally faster -- that's why I suggest the size
of the array I do. A little digging into drive specs will show why...

Will R
PMC Consulting

What kind of workstation

Post by Loren Szen » Thu, 15 Mar 2007 17:41:02

Serial Attached SCSI has been floating around my office by the hardware
freaks as the best way to go. I asked them if they would recommend it
over SCSI, and they said yes.

Raid 5 is amazing, but lately I have heard of quite a number of
installations where more than one disk failed on the same day. So if you
use it, don't get complacent.

Bill Todd's advice is best, however: throwing expensive hardware at a
problem usually has much less effect than anticipated. I've seen
unbelievable amounts of money spent on very high-end servers to try and
solve extremely slow running SQL Server databases, all of which resulted
in almost identical performance numbers.

Random thoughts.


What kind of workstation

Post by Van den Wo » Fri, 16 Mar 2007 05:12:05


I believe that following items are more important than solving
performance problems with buying expensive hardware:

* data-model (good normalization)
* tuning queries (forcing using the correct indices if the engine isn't
* Use stored procs
* balancing page-buffers, sort-memory etc vs total memory on server
* separate data, journaling files (IB2007) and temporary files (sorting,
etc) onto different disk-controllers
* If reports are a problem, try to create replication DB(s) and redirect
your reports onto these DB. So you can tune the original DB for writing
(OLAP) and the other DB for data-mining.
* If you have too much concurrent user, write a n-tier application with
connection-pooling instead of fat-clients

I have a lot of cases when customers have performance problems, and
after revising some structures (indices, create stored procs, etc..) and
queries the problem is solved. It is rare that you need a very powerful
server, if you need that then it is probably time too pay for Oracle, DB/2.

Raid 5 isn't very good at writing, so if your application does a lot of
DML-statements, then it is better to use RAID 10. Best of 2 worlds,
fast reading/writing and mirroring.

Van den Wouwer Danny
Peopleware NV

What kind of workstation

Post by Will » Fri, 16 Mar 2007 14:53:54

an den Wouwer Danny wrote:

** Business Rules First ***

**a and different drives obviously ***

This used to be my first tactic on large Multi user mainframes -- I
usually went no further in my "bag of tricks" as load balancing usually
fixed the problem with data bases and large system compiles...

Plus separate drive and/or controller for paging files as opposed to the
OS -- on big busy systems.

***** > Raid 5 isn't very good at writing, *****


so if your application does a lot of

AMEN again!!! Which is why I specified that backup systems should be
designed in... Afterthoughts don't always work...

Well yeah I agree with all of that -- but I was just answering the
question as I pointed out -- since other people were kindly supplying
the rest of the info. :-)

To that end I use a CASE tool for my database design. Then I can fool
with refinements to no end... :-)

On this project the database generation including triggers for cascaded
updates and deletes is about 21000 lines of code -- about 300 tables.
Tough to do as a "hack".

So far no speed problems are apparent in the test data -- which is kept
small -- no grater than 200,0000 entries per table.

We are expecting to see millions of rows in some tables. So bad design
would kill it...

But I might suggest a set of Business Rules before the data model as
Normalization is defined by the business rules (at least in my book...)

Will R
PMC Consulting

What kind of workstation

Post by Eric ten W » Fri, 16 Mar 2007 22:43:36


Thanks for all the answers.

Problem is that i use ReportBuilder *crystal report like) end user tool, and
i have made views for the users so they have not to make all joins

The user can make not the best joins there are and many view joins he makes
do not work with Interbase (giving error "No current record for the fetch
Also the where clauses are often like "Where country is "Holland"" where
"Where country_id = 25" is much faster.

Still wonder wy some (inner) joins result in No current record for the fetch