--- In firebird-support@yahoogroups.com, "c_pradelli"
<c_pradelli@y...> wrote:

>
> > If you have other ideas in how to help us on this it will be very
> > appreciated. I will continue to work on this during the Holidays.
>
> Please do this test:
>
> Use Firebird 1.5 Classical Server, and enable again HT.
>
> Please make know the results.

Pradelli:

I reinstalled Firebird 1.5 RC8 Classic Server without enabling HT. I
tested the application again and the performance was the same.
I enabled the HT and after running the application the results was
the same.

We decided to prepare a small application in order to get a
consistent test environment. The application is a program that access
a table (just integer numbers) with 1200 records. The application
first read 100 records based in a user number (I mean user number 1
read records from 1 to 100, user number 2 reads records from 101 to
200, and so on until user number 12 that reads the last 100 records
from the table). We used DBExpress and a very simple SQL command to
read data:

' select * from POTENCIA'+
' where Num between '+IntToStr((V_IdUser *
QuantidadeRegistroSelect)-(QuantidadeRegistroSelect -1))+
' and '+ IntToStr(V_IdUser * QuantidadeRegistroSelect)+
' order by Num';

With the data in a ClientDataSet we did some calculation (add,
divide, etc.) to spend some time and save the data. We use the
following to save:

try
GravarLogComMilisegundo('Antes de Gravar Dados', Now, V_IdUser);
{ V_Transacao.TransactionID:= V_IdUser;
V_Transacao.IsolationLevel:= xilREADCOMMITTED;
SQLConnection.StartTransaction(V_Transacao);}
If CDS.ApplyUpdates(0) <> 0 then
Begin
SQLConnection.Rollback(V_Transacao);
MessageDlg('Erro no ApplyUpdates ao Gravar os Dados' ,
mtInformation,[mbOk], 0);
end
else
Begin
SQLConnection.Commit(V_Transacao);
GravarLogComMilisegundo('Depois Gravar Dados', Now, V_IdUser);
Result:= True;
end;
except
on E: Exception do
Begin
SQLConnection.Rollback(V_Transacao);
MessageDlg('Erro ao Gravar Dados - ' + E.ClassName +
' - '+ E.Message, mtInformation,[mbOk], 0);
end;
end;

We developed another application that run the test 12 times (we used
a timer to be sure all the application could start at once so we can
verify if the FB can handle all users at once)

The results we could find is almost strange (at least for us) as the
simulation application.

For FireBird SuperServer and for only one user we got:

Reading time: 125 miliseconds
Calculation time: 510 miliseconds
saving time: less than 1 milisecond
Total time: 675 miliseconds

For FireBird Client and for only one user we got:

Reading time: 343 miliseconds
Calculation time: 516 miliseconds
saving time: less than 1 milisecond
Total time: 859 miliseconds

We used the one user numbers to compare the results with the 12 users.

For FB SuperServer the numbers are:

Reading time: 1296 miliseconds
Calculation time: 5672 miliseconds
saving time: less than 281 milisecond
Total time: 6015 miliseconds

For FB Classic the numbers are:

Reading time: 1359 miliseconds
Calculation time: 5797 miliseconds
saving time: less than 3937 milisecond
Total time: 5937 miliseconds

We collected the time results for each client itself and here come
the strange situation. For both the FB Classic and SuperServer the
results shows individualy times for reading ranging from 343
miliseconds to 1296 (in some tests we got numbers from 93 to 3391
miliseconds).

It seems to us that FB cannot work with multiusers requesting data at
once due to we cannot see any possibility of records locks (we can
understand that table lock could be possible, but not expected).

We could expected total reading results near 3000 miliseconds or less
and never 5600+.

Can someone help us on this? This kind of performance could not be
acceptable for 4 users test in the simulation environment (5 minutes
to run).

I can provide more details about the test if necessary.

Regards, and hope you could help us on this,

Wagner Bazarin
Mac-Penn
Brazil