Dear Helen

I have forward your message to the implementator. Now we have to
install a Borland Interbase Database driver local. Will this work
because we have a "VERY old database?

The performance with SQL is now match better.

We have also move the firebird to a normal PC (with a dual core
processor). We will test with the HP Server next week.

I have hear, that in the October or so a new Firebird versin with
multiprocessor support will come. Is that true?

Tanks again for your help

Greetings from Switzeland

Haija




--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...>
wrote:

>
> At 11:28 PM 16/06/2008, Haija wrote:
>
> >Here the gstat:
> >
> >D:\Database>gstat -h msup.fdb
> >
> >Database "msup.fdb"
> >Database header page information:
> > Flags 0
> > Checksum 12345
> > Generation 21260075
> > Page size 4096
> > ODS version 11.0
> > Oldest transaction 21260066
> > Oldest active 21260067
> > Oldest snapshot 21260067
> > Next transaction 21260069
> > Bumped transaction 1
> > Sequence number 0
> > Next attachment ID 0
> > Implementation ID 16
> > Shadow count 0
> > Page buffers 0
> > Next header page 0
> > Database dialect 1
> > Creation date Feb 13, 2008 20:13:13
> > Attributes force write
> >
> > Variable header data:
> > Sweep interval: 20000
> > *END*
>
> At this level, the header stats look very good. A next step would

be to get the index stats using gstat -i. Use the IB 6 beta
Operations Guide (or The Firebird Book, if you have it) for the
syntax to output the results to a text file. The index stats can be
useful for identifying indexes that don't perform well.

>
> It is noted that, although the ODS is 11.0, this database was not

created by Firebird 2. "Dialect 1" tells us that this is a VERY old
database, that was created by an InterBase 5.6 or older engine.
Amongst other things, this makes 8 years of improvements in Firebird
unavailable. Possibly the old database was never upgraded due to
incompatibility with whatever is being used as the database access
layer. We still don't know. You owe it to yourself to find out.

>
> >The app is written in Delphi.
>
> That doesn't tell us what the database access layer is. If you

have the source code, get the names of the data access components.

>
> >Again: When i start a query from the client, i see a lot

of "Writes

> >to database". I expect to see "Reads from database". For me not to
> >explain.
>
> And, AGAIN, *we* have no way to tell why this is so. It is quite

likely that the tool you are using, or the application code, is
creating temporary structures and making writes to these structures.

>
> You have already told us that each instance of the client

application is writing data across to the server every 30 seconds.
Why would you expect not to see writes?

>
> If you are running tools in the background constantly, that do

expensive operations, then you can expect performance to go down. On
the other hand, unfortunately there are lots of old Delphi
applications out there that use techniques which are very bad for a
database engine designed for multiple concurrent users over network
connections.

>
> >Shall i install the ClassicServer for Tests on the MultiProcessor
> >Server or is this a bad idee?
>
> It is a separate issue. The architectural difference between

Classic and Superserver is that SS is a single process that spawns
threads for client connections (and other tasks), whereas Classic
creates one process for each client connection. A 32-bit process on
Windows is limited to a maximum of 2 GB of RAM and Firebird's
threading model does not support SMP. Therefore, if the problems
with SS are related to inadequate RAM then it would be worthwhile to
test Classic and see whether the availability of extra RAM improves
anything.

>
> If you do this, you must make sure that your firebird.conf

parameter DefaultDbCachePages has a much lower setting than the
default 2048 that is set for SS. This is because each Classic
process has its own private cache, not a shared one as in SS. I
suggest 128. The server will have to be stopped and restarted after
this change.

>
> But keep in mind that it is the SAME database engine. If your

applications are doing horrible things that cause undesirable writes,
it makes no difference whether you are running Classic or SS.

>
> Please trim your messages!
>
> ^ heLen
>