Pete/Roger,

Converting the long varchars to blobs to reduce bandwidth make a lot sense
as the data packet will not contain the data of the field, just the blob
identifier which is pretty small. varchars are also (I believe) sent in the
packet as their full width, not the data only part (ie a varchar(50) with 10
chars of text will be sent with the extra 40 spaces on the end).

Of course the performance of an IB/FB database will always be better after a
backup and restore cycle to remove the garbage, and physically set the data
in table order, and reoptimize the indexes. Sweep can on-line garbage
collect, disabling and re-enabling the indexes optimize them online as well,
but the physical placement can only be done off-line during a restore. You
will find that most people have an off-line backup and restore cycle running
on a regular basis. For this to be effective, all users *must* be
disconnected from the database until the restore has finished.

Rich P...

-----Original Message-----
From: Pete Bray [mailto:pete@...]
Sent: 11 September 2003 10:25
To: firebird-support@yahoogroups.com
Subject: RE: [firebird-support] Dedicated Servers

> This server is dedicated to these 2 db's
> but I feel they should have their own server
> now as performance is deteriorating.
>
> I need to put a case forward to spend the money -
> are there any papers out there on this
> (I have the "Make IB scream" one which goes
> some way but does not cover one or
> two databases and performance etc)

Roger,

i have a similar scenario to yours. a w2k server (cpu < 1GHz), raid scsi. 3
IB6 databases, one with 3 users, one with up to 10, and one being hit pretty
hard by 20. over the course of a day, you should be able to see from the
task manager how processor intensive the IBserver process task has been.

i bit the bullet recently and changed the main app so that no transactions
are held open. all data that is displayed in the client is held in local
(RxMemeryDataset) storage. i'm using FIB components and use the basic query
component to grab the data and copy it in to the MemoryDataset. Inserts and
updates are also performed using this component (ie no dataset descendents
are ever attached to the database). keys are either generated by triggers,
or from locally generated GUIDs so that an Insert only requires a single
'conversation' with the server. i ran an sql monitor to watch the queries as
they were fired off and found that quite a lot of times i could cut the
traffic by more complex join queries rather than sending 3 seperate ones.
the main rational behind this change was to improve the performance for the
remote users who are accessing through the internet via SSH, however there
have been noticeable benefits to LAN users as well (especially the change
from long VarChars to Blobs which was taking a lot of network bandwidth in
and out of the server).

i don't know if any of this is relevent to your situation, and it may be
that i am only slowly learning what everybody else already knows, but i
thought i'd share my findings anyway :)

Kind regards,
Pete



To unsubscribe from this group, send an email to:
firebird-support-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/