Subject Re: [firebird-support] Small Database with very very bad performance on LAN
Author Daniel Rail
Hi,

At January 8, 2016, 7:50 AM, Luigi Siciliano luigisic@... [firebird-support] wrote:

> Hallo,
> I have a small database (less 100MB) that works on Firebird 2.5.5
> SS64bit over a machine with Win7 64bit with 4GB Ram, CPU Pentium G620.

> I seems to work very well in local but with the 3 clients on LAN works
> very bad. It is very very slow to open and navigate a simple table with
> less of 5.000 rows!

> What i can do?

Have you tried with SuperClassic or Classic? SuperServer 2.5.5 still
is a single thread per database, so basically all connections to one
database, all share the same thread. While SuperClassic, uses one
thread per connection and Classic uses one instance per connection.
With SuperServer 3.0, it will be a true multi-threaded environment
where you shouldn't see this kind of performance hit, since each
connection should be using their own thread.

At the beginning, we were using SuperServer, but after customers
reporting slowdowns, when at least one user was doing something in the
software that did use a lot of resources out of Firebird(i.e.: a
report with data analysis). We decided to try Classic(SuperClassic
wasn't available at the time), and our customers are not longer
reporting those slowdowns.

So, give Classic or SuperClassic a try. Unless, if you still want
SuperServer, give Firebird 3 Superserver Release Candidate 1 a try.

> I very novice in Firebird.

> The result of gstat is:
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 26613
> Page size 4096
> ODS version 11.2
> Oldest transaction 26603
> Oldest active 26604
> Oldest snapshot 26604
> Next transaction 26605
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 139
> Implementation ID 26
> Shadow count 0
> Page buffers 0
> Next header page 0
> Database dialect 3
> Creation date Jan 4, 2016 15:44:10
> Attributes force write

> Variable header data:
> Sweep interval: 20000
> *END*

These stats are really good. Are they taken when the slowdown occurs,
with all the connections and queries active, or is it after they are
closed? Also, make certain that you are using a read-only transaction
for reading the data and use a short read/write transaction to
insert/update/delete data.

--
Best regards,
Daniel Rail
Senior Software Developer
ACCRA Solutions Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)