Christian,

and another benchmark note.

We imported textdata from a cd to the db by defining these textfiles as
external tables and reading them by a stored procedure which also did
the insert.

On a PII 400, 196 MB Ram, Win 98, IB 5.6 local we made up to 5000
records per second, each record approx. 400Byte.

So I think with another hardware equipment (PIII, Raid) you might get up
to 10000....


Did you also test the insert with an DSQL-statement?
I'd be interested in the differnece between INSERT INTO with an
TIB_Query and a TIB_DSQL.

Luc.


Christian Kaas schrieb:

>
> Hi folks,
>
> I just had to make my own benchmarks on this:
> Table structure:
>
> CREATE TABLE TEST (TEST_ID numeric(7) not null,
> test_text varchar(30),
> constraint pk_test primary key(test_id)
> );
>
> Insert with TIBOQuery (TDataset) traditional Append, Post:
> ----------------------------------------------------------
>
> 1000 Records local IB Win2k Pentium III 800Mhz, 256MB RAM: 1 second
> 1000 Records remote IB on Suse Linux 6.4 PII 350MhZ 256MB RAM: 2 seconds
>
> Insert using T_IBQuery Prepared Insert statement with Params
> ------------------------------------------------------------
> 20000 Records local IB Win2k Pentium III 800Mhz, 256MB RAM: 3.5 seconds
> 20000 Records remote IB on Suse Linux 6.4 PII 350MhZ 256MB RAM: 10
> seconds
>
> Times were measured just before calling TIB_TransAction.Commit;
>
> Never got such times when running oracle on those boxes !
>
> VERY VERY NICE - IB with IBO rock'N'rolls! I am really pleased with the
> results!
>
> --
> Christian Kaas mailto:christian@...
> Client/Server/Internet/Multitier development
> http://www.ckaas.de
>
> > -----Ursprungliche Nachricht-----
> > Von: Jason Wharton [mailto:jwharton@...]
> > Gesendet: Montag, 8. Januar 2001 22:27
> > An: IBObjects@egroups.com
> > Betreff: Re: [IBO] Interbase,Advantage,Paradox
> >
> >
> > > > 1. If it's performance you are seeking, there is NO WAY
> > you should be
> > > > using TIBOTable for an executable process. Put this
> > statement into a
> > > > TIBOQuery...
> > >
> > > Would a TIB_DSQL component not perform better for bulk
> > inserts since it
> > does
> > > not have the extra baggage associated with the TIBOQuery component ?
> >
> > Yes, this is the best component to use for batch inserts.
> >
> > > > 3. Forced writes will slow things down (as observed) but
> > if you have a
> > > > fragile network environment or users who habitually
> > terminate a database
> > > > session by switching the computer off, it's worth the cost.
> > >
> > > Really ? I have client sites where the users habitually terminate a
> > database
> > > session by switching the computer off. I have been trying
> > to break them of
> > > this habit for years, but without success. I was under the
> > impression that
> > > IB would solve this problem due to it's C/S design. What
> > kind of problems
> > > can I expect when this happens ? I realize that any pending
> > transactions
> > > will not be committed, but please tell me my database will
> > still be intact
> > ?
> >
> > You are safe with InterBase. The only reason you want forced
> > writes on is if
> > you SERVER is ever susceptible to a power failure or your OS
> > install is in
> > flaky condition.
> >
> > What I usually do is leave forced writes on and when I am
> > doing some hard
> > crunching in a batch job I turn them off temporarily and put
> > them back on
> > again when I am done. I usually always have a backup prior to
> > doing major
> > crunch updates/loads to my database in case something does go wrong.
> >
> > A failed client will not adversely affect the server's data integrity,
> > period. That's client server.
> >
> > > > As a general comment, it doesn't make sense to force
> > InterBase to behave
> > > > like a file-based database (which it's not) and then expect it to
> > compare
> > > > favourably with file-based databases, performance-wise.
> > The kind of
> > > > "benchmark" you are trying to do is rather silly, for
> > example, because
> > one
> > > > would never be inserting 1000 records from a table interface. The
> > Insert
> > > > and Append methods are intended for one-by-one manual inserts.
> > >
> > > I agree that this is a silly test, but it is probably one
> > of the first
> > tests
> > > that every BDE to IB convert tries. The table interface gives the
> > developer
> > > the warm fuzzies they had with the BDE TTable component and
> > is a natural
> > > selection.
> >
> > Get over it!
> >
> > > > A further comment is this. Client/Server databases
> > aren't intended for
> > > > desktop use. If speed is your only criterion then stay
> > with the desktop
> > > > database. The transaction model is meant to preserve
> > data integrity in
> > a
> > > > multi-user environment. It would be surprising if there
> > were no cost to
> > > > that. If your single-user app is getting broken by user
> > behavior under
> > > > Paradox, it won't get better by switching to another database.
> > >
> > > I would imagine that the majority of people migrating from
> > Paradox to IB
> > are
> > > switching for the improved multi-user support, but still
> > need to support a
> > > single user environment. I have found that IB performs
> > quite well in a
> > > single user environment as long as the app and database are
> > designed to
> > take
> > > advantage of IB's strengths. Reads, inserts and updates all
> > appear to be
> > > much faster. Could you elaborate on where IB might be
> > slower ? This could
> > be
> > > very helpful to newcomers like myself.
> >
> > IB will be slower than paradox if you are not taking
> > advantage of any of the
> > additional features and capabilities that InterBase has. With
> > hardware ever
> > increasing I really don't think this is a significant performance gap.
> > InterBase is so efficient that it can and will do a good job
> > in a single
> > user environment.
> >
> > FWIW,
> > Jason Wharton
> > CPS - Mesa AZ
> > http://www.ibobjects.com
> >
> >
> >
> >
> >