Subject | Re: [firebird-support] Large Firebird 1.5 database |
---|---|
Author | Alexandre Benson Smith |
Post date | 2004-07-23T01:09:13Z |
Fred Gordon wrote:
I don't have much experience with "large" databases my bigger db has
1.3GB (without blobs), and my large user base are around 20 users.
5 million records could be handled in a way to give sub-second response
time (if indexed carefully), The main reason for poor performance on FB
is bad queries (some correlated queries, select count(*) from aTable) or
large result sets that must be fetched over the wire, and transactions
open for a long time.
I am sure you will get more responses on this thread.
Search the historic of this list, this subject are frequently discussed
here...
But as a start, take a look on Bill Karwin article "10 ThingsYou can do
to Make Interbase Scream" (interbase and firebird still has a lot in common)
Use Prepared Queries as much as possible
Keep transaction time short
Look the queries plan and indices used, and see if could be improved
Try to minimize the amount of data that need to cross the wire.
Somethings should be done diferently in FB than you are used to do in
Informix, so if you find a piece os SQL that runs with a drastic
performance diference between what you got in Informix and the current
FB, post your querie here, someone you try to improve it and show you
how is the best way to do it in FB.
A good hardware will help (as with any other SGDB, I am sure you know
it) :-)
And a side note....
Maybe you could have better results using Classic Server, in Classic you
could use SMP machines, and the mean reponse time are not affect but
heavy queries
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
>I am working on a project to convert several old informix standardFred,
>engine databases over to a new platform. I converted a small database
>and have been doing some testing and so far Firebird (super server)
>seems to be working wonderfully.
>
>Does anyone on this forum have any experience using Firebird in a large
>production environment? I know that large is relative.... some of the
>system that I need to convert have as many as 50 concurrent users and
>several tables with 5 million+ records. The databases grow to 10 or so
>gigs. So when I say large I mean to large for ms access not oracle :-)
>
>We will be using Tomcat and JDBC to access the database.
>
>Thanks,
>Fred.
>
>
I don't have much experience with "large" databases my bigger db has
1.3GB (without blobs), and my large user base are around 20 users.
5 million records could be handled in a way to give sub-second response
time (if indexed carefully), The main reason for poor performance on FB
is bad queries (some correlated queries, select count(*) from aTable) or
large result sets that must be fetched over the wire, and transactions
open for a long time.
I am sure you will get more responses on this thread.
Search the historic of this list, this subject are frequently discussed
here...
But as a start, take a look on Bill Karwin article "10 ThingsYou can do
to Make Interbase Scream" (interbase and firebird still has a lot in common)
Use Prepared Queries as much as possible
Keep transaction time short
Look the queries plan and indices used, and see if could be improved
Try to minimize the amount of data that need to cross the wire.
Somethings should be done diferently in FB than you are used to do in
Informix, so if you find a piece os SQL that runs with a drastic
performance diference between what you got in Informix and the current
FB, post your querie here, someone you try to improve it and show you
how is the best way to do it in FB.
A good hardware will help (as with any other SGDB, I am sure you know
it) :-)
And a side note....
Maybe you could have better results using Classic Server, in Classic you
could use SMP machines, and the mean reponse time are not affect but
heavy queries
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br