--- In firebird-support@yahoogroups.com, "diegodelafuente" wrote:

> if the problem is a Badly written application the problem, I can
> seek the bad code recreating with 2 o 3 pcs and another server where
> is the problem (running the proceess and compare the CPU
> utilization). That was done, but we coudn´t find something bad.

If the data is identical, such a test would reveal very badly written
SQL. It would not catch things like long-running transactions, and the
not-all-too-bad-but-could-be-improved SQL may avoid getting caught
(like SELECT COUNT when you're only interested in knowing whether
there is one or more tuples). Try running some statistics when
performance is slow and report to the result to this list. I don't
know much about the statistics, just that a too large gap between
'oldest active transaction' and 'next transaction' can be bad and lead
to the database starting a SWEEP unless the sweep interval is set to 0
(sweeping removes outdated rows, but the database may be unresponsive
while the sweep is taking place). Depending on how your users access
the database, they may also be the source of your problems. E.g. if
some of them frequently checks which name in South America is the most
popular and which name was the most popular amongst the grandfathers
of people with that name (subselect with self joins etc.), then you
may run into trouble with your performance long before you get 70 users.

Set