Subject | Re: [IBO] development |
---|---|
Author | Geoff Worboys |
Post date | 2010-03-21T07:34:12Z |
Hi Hans,
your apparent conclusion about "IBOBject development going in
the right direction" is... appropriate to the situation.
There are lots of nit-picky details about how to get the
absolute best possible transfer speeds... but for such a
small 128M database to take 32 minutes to transfer means we
are looking for BIG problems (I can generally backup a 2Gb+
database in that sort of time using DBak, which uses IBO, on
reasonably current hardware).
I was wondering about your use of Append... but for a cursor
this should be the equivalent to an insert anyway I think.
Believe me, 32 minutes almost certainly means that there is
something very wrong! (I would have suggested that your
database had triggers doing something elaborate... but that
would have shown against the FBPlus stuff too.)
I would suggest trying IBO v4.8.7... although I cannot see
anything in the release notes that would suggest a problem
of this nature in v4.8.4. What I do know is that I have been
using v4.8.7 without major issues for a long time now.
I have still not updated DBak for FB v2.1... but it might work
if you are not using newer feature (database triggers). You
could try that: http://www.telesiscomputing.com.au/dbk.htm
and see what sort of transfer time it gives.
If your transfer provides visual feedback it could be worth
noting whether the IBO transfer works smoothly (albeit slowly)
or whether it seems to freeze for periods of time.
I would probably also try some experiments with SQL monitor
to see if you can see very long prepare times or excess queries
taking place etc... basically I think you need to do what you
can to isolate exactly what part of the processing is taking
most of the time (is the post slow, the field assignments,
the append or whatever). Check the memory consumption, is it
growing with every transfer (indicating excessive caching of
some sort - perhaps blobs, IBO historically got a bit carried
away with caching blobs).
32 minutes is a problem in itself... once we reduce that by an
order of magnitude we can discuss how tranfer times between
your processing and FBPlus compare.
None of this is to claim IBO as perfect, or that I agree with
it's development direction... however I consider those quite
separate questions to your real problem of 32min for 128Mb.
--
Geoff Worboys
Telesis Computing
> Then I downloaded a test copy of FIBPlus 6.5, [...] andThis is an interesting result. I am not at all certain that
> merely replaced the IB_Cursors with their tpFIBDataset,
> for the rest using the almost identical coding as I used
> for IBObjects.
> [...]
> FIBPlus about 21+ times faster than IBObjects.
> My concern, as a long time supporter of IBObjects since the
> early versions V3.xx, is the IBObject development going in
> the right direction ?
your apparent conclusion about "IBOBject development going in
the right direction" is... appropriate to the situation.
There are lots of nit-picky details about how to get the
absolute best possible transfer speeds... but for such a
small 128M database to take 32 minutes to transfer means we
are looking for BIG problems (I can generally backup a 2Gb+
database in that sort of time using DBak, which uses IBO, on
reasonably current hardware).
I was wondering about your use of Append... but for a cursor
this should be the equivalent to an insert anyway I think.
Believe me, 32 minutes almost certainly means that there is
something very wrong! (I would have suggested that your
database had triggers doing something elaborate... but that
would have shown against the FBPlus stuff too.)
I would suggest trying IBO v4.8.7... although I cannot see
anything in the release notes that would suggest a problem
of this nature in v4.8.4. What I do know is that I have been
using v4.8.7 without major issues for a long time now.
I have still not updated DBak for FB v2.1... but it might work
if you are not using newer feature (database triggers). You
could try that: http://www.telesiscomputing.com.au/dbk.htm
and see what sort of transfer time it gives.
If your transfer provides visual feedback it could be worth
noting whether the IBO transfer works smoothly (albeit slowly)
or whether it seems to freeze for periods of time.
I would probably also try some experiments with SQL monitor
to see if you can see very long prepare times or excess queries
taking place etc... basically I think you need to do what you
can to isolate exactly what part of the processing is taking
most of the time (is the post slow, the field assignments,
the append or whatever). Check the memory consumption, is it
growing with every transfer (indicating excessive caching of
some sort - perhaps blobs, IBO historically got a bit carried
away with caching blobs).
32 minutes is a problem in itself... once we reduce that by an
order of magnitude we can discuss how tranfer times between
your processing and FBPlus compare.
None of this is to claim IBO as perfect, or that I agree with
it's development direction... however I consider those quite
separate questions to your real problem of 32min for 128Mb.
--
Geoff Worboys
Telesis Computing