I am running fairly simple transactions.

TPC-B has a fairly simple schema. There are three tables: accounts,
branches and tellers.

ACCOUNTS(accountid integer, branchid integer, accountbalance integer,
junk char(88), primary key(accountid))

TELLERS(tellerid integer, branchid integer, tellerbalance integer,
junk char(88), primary key(tellerid))

BRANCHES(branchid integer, branchbalance integer, primary key(branchid)

I am running with 1 branch, 10 tellers, and 100,000 accounts

I am running with 20 clients, and am getting 20TPS. With 1 million
accounts I was getting 10TPS. I upped the cache size using gfix to
10,000 and got 5TPS.

They are all prepared, but I am noticing that it is prepared each time
prior to execution. I can fix that, but I think my point is that I am
running exactly the same code on Pointbase, which is running at about
120 TPS,, and on MySQL which is running at over 1000 TPS. So Firebird
is just not comparing well. Are repreparing statements in Firebird
significantly costly?

David

David Zvekic wrote:

> What are you doing during your transactions? a transaction can be many
> different things. I have
> transactions which takes many minutes to complete.
>
> The question is: what exactly is the test that you are performing?
>
> Are you preparing an SQL statement during each transaction, and
> unpreparing and repreparing that SQL statement
> each time?
>
> Taking 100 milliseconds to prepare and optimize an SQL statement would
> not suprise me at all.
>
> The question then is. do you really need to unprepare that statement, or
> can you reuse it.
>
> more info is needed
>
> Also:
>
> deadlocks are not a bug (in the database server anyway).
>
> A deadlock occurs when user 1 tries to modify ROW A, User 2 tries to
> modify ROW B, and then either
> User 1 tries to modify ROW B
> or
> USER 2 tries to modify ROW A.
>
> Neither user could ever possibly get their work complete because both
> users are waiting on the other
> user to complete their work which they can't ever complete because they
> are also waiting on the other.
>
> Interbase (and presumably firebird) would report this as a Deadlock
> error and rightfully so. It would cause one or both
> of the users to unblock and report the error.
>
> This is not a bug.
>
> How would you have Firebird handle this situation?
>
> What is the specific error message you are getting, and what is the
> exact situation under which it occurs.
>
> more info needed
>
> DZ
>
> david_vanc wrote:
> > Hi, all. I am running some performance tests against Firebird, and to
> > be honest, it really stinks. For a single client I am getting only
> > around 10 TPS. I am sure I must be doing something wrong.
> >
> > First, let me be clear, I don't want to do a test with write-through
> > turned off, because it is crucial that data is guaranteed to be there
> > if Firebird goes down. Writing to disk after a commit is not
> > acceptable for my application.
> >
> > But the other thing that appears to be happening is with more than one
> > client, I immediately get deadlocks.
> >
> > Is there a way to configure Firebird to improve its overall
> > performance without turning off write-through? Is there a way to get
> > rid of the deadlocks?
> >
> > Thanks,
> >
> > David
> >
>
>
> *Yahoo! Groups Sponsor*
> <http://us.ard.yahoo.com/M=249982.3083889.4452939.1728375/D=egroupweb/S=1705115386:HM/A=1524963/R=0/*http://hits.411web.com/cgi-bin/autoredir?camp=556&lineid=3083889&prop=egroupweb&pos=HM>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/>.