Dear Members,

I have added more than 10 million records(Two tables each with 5
million). And my application keep running for the past two and half days.

After data insertion I have spawn a thread fetching the record count
and fetching 200 records (randomly e.g 1 to 200 or 110 to 310 etc)
with in the total record count limit. I have observed that count
query takes more time ( approximately 2 secs) more than data fetch.

Note : Data dumping is completely stopped. Only above specified data
fetching is in progress.

My database size has grown to 1.28GB .

Is 'count(*) query performance' goes down when record count increases?

Since firebird maintains the data in single won't it degrade db
performance. If I am wrong kindly update me. Is ther is any way to
split the db in different files. I think we can create table with
separte file. Is there is any configuration so that firebird can split
the data in different files and manage it.

I will further continue with my load test I will update you with my
further observations,

Thanks & regards,
S.Karthick

--- In firebird-support@yahoogroups.com, Nando Dessena <nandod@d...>
wrote:

> Hello,
>
> k> Embedded Server :
>
> actually "embedded engine", or just fbembed. There's no server.
>
> k> In case of embed I hope it will suit for smaller applications.
> k> (If I am wrong kindly correct me). But in case of larger applications
> k> i.e. when the application need to handle millions of record. I am not
> k> sure of the the scalability of embedded database process. Is there is
> k> any specific things to be handled in such a case.
>
> I can't help you because I don't deal with very large amounts of data
> (except in one case, in which I have actually migrated from Oracle to
> fbembed for speed, but the records are very small there).
> Yet I can't see why an embedded engine would be less adequate than a
> stand-alone one for the task.
>
> k> Do you prescribe me to use not to use embedded DB in such a case?
>
> Well, since switching is a matter of changing the connection string
> and nothing else, you have both paths open 24 hrs/day. I suggest you
> start with embedded, monitor it in a reasonably realistic environment,
> then switch to firebird stand-alone and draw your conclusions.
> I can imagine that you can trade some throughput (because you're going
> to need a TCP connection to the firebird server - even locally) with
> the ability to put the server in a separate box and gain scalability.
>
> k> When Separate Database server is packaged:
>
> k> Since we package the DB server along with our application. We need
> k> to start the dbserver when the db gets started and stop it when our
> k> application gets stopped. Similar to "fbmgr" in linux is there is any
> k> equivalent tool in windows, to stop the firebird server in windows.
>
> what I do is start a separate, private fbserver.exe when my (service)
> application starts, and stop it (with TerminateProcess(),
> unfortunately, but I take precautions to avoid shutting down the
> server when a database is in use). All you need to do for this to
> succeed is set the FIREBIRD environment variable in the environment
> block of the called fbserver.exe process before starting it, and
> possibly choose a TCP port different from 3050 to avoid collisions
> with other instances of Firebird or InterBase on the target machine.
>
> Ciao
> --
> Nando Dessena
> http://www.flamerobin.org
> ======================================================
> I support Firebird, I am a Firebird Foundation member!
> Join today at http://www.firebirdsql.org/ff/foundation
> ======================================================