Subject | [IBO] Re: For Fabiano Bonin |
---|---|
Author | Carlos Macao |
Post date | 2004-03-30T17:30:30Z |
Hi Jason,
<<<
IBO Query IB_Query FIB Dataset
Connection 6.939 5.448
Open and Select 29.681 22.311 49
Open and Select
with Schema Cache 6.129 6.007 39 >>>
<<< I don't get it, IBO did something in 22.311 units of time that
FIB+ took 49.000 units of time and IBO is worse? By my estimation IBO
is twice as fast as FIB+ on this case. Then, looking at 6.007 seconds
compared to 39 seconds is much, much faster by magnitudes. Perhaps
you are referring to the connection time taking over 1 second longer
only and ignoring these other figures? >>>
Well I am a little ashamed because all the values are in
milliseconds. Ok, I know even a remote ping can long more than 49 ms,
there was a bug in my benchmark program and the FIB fetch times were
measured over a local connection.
Meanwhile I retest everything with a little more care and I discover
that one of the causes of the bad fetch times were related with this
particular ISP which has a service for compress/uncompress web data,
for speed proposes, and this somehow is affecting the Firebird
protocol.
The new tests were made over the same environment (except for a
different ISP 45K line) but the new select increased the number of
rows from 100 to 2063, the dataset are attached to a TDBGrid or
TIB_Grid. These are the numbers, without schema cache:
TIBOTable IBO Query IB_Query FIB Dataset
Connection 3,030 3,765 2,980 2,889
Open and Select 37,609 10,843 9,250 7,047
Close Query 1,062 1,032 186 188
Close Connection 971 780 734 1,062
Conclusion: to avoid IBOTables and use IBOQuery, which we already
knew. Butafter all there is a noticable diference beetween IBO
dataset solution as oposed to FIB, but I am working on more complete
tests, including inserts, deletes and updates and with schema cache,
and next weekend I'll send you the benchmark program.
<<< I could easily set things up so you can shave that time down. IBO
is simply getting the connection characteristics so it knows what
ODS it is working with and a few other things. These could be
suppressed if you supplied the information manually. Then, you could
have your much faster operations and a significantly faster connect
time as well. >>>
I think these conections times are acceptable.
Best Regards,
Carlos Macao
<<<
IBO Query IB_Query FIB Dataset
Connection 6.939 5.448
Open and Select 29.681 22.311 49
Open and Select
with Schema Cache 6.129 6.007 39 >>>
<<< I don't get it, IBO did something in 22.311 units of time that
FIB+ took 49.000 units of time and IBO is worse? By my estimation IBO
is twice as fast as FIB+ on this case. Then, looking at 6.007 seconds
compared to 39 seconds is much, much faster by magnitudes. Perhaps
you are referring to the connection time taking over 1 second longer
only and ignoring these other figures? >>>
Well I am a little ashamed because all the values are in
milliseconds. Ok, I know even a remote ping can long more than 49 ms,
there was a bug in my benchmark program and the FIB fetch times were
measured over a local connection.
Meanwhile I retest everything with a little more care and I discover
that one of the causes of the bad fetch times were related with this
particular ISP which has a service for compress/uncompress web data,
for speed proposes, and this somehow is affecting the Firebird
protocol.
The new tests were made over the same environment (except for a
different ISP 45K line) but the new select increased the number of
rows from 100 to 2063, the dataset are attached to a TDBGrid or
TIB_Grid. These are the numbers, without schema cache:
TIBOTable IBO Query IB_Query FIB Dataset
Connection 3,030 3,765 2,980 2,889
Open and Select 37,609 10,843 9,250 7,047
Close Query 1,062 1,032 186 188
Close Connection 971 780 734 1,062
Conclusion: to avoid IBOTables and use IBOQuery, which we already
knew. Butafter all there is a noticable diference beetween IBO
dataset solution as oposed to FIB, but I am working on more complete
tests, including inserts, deletes and updates and with schema cache,
and next weekend I'll send you the benchmark program.
<<< I could easily set things up so you can shave that time down. IBO
is simply getting the connection characteristics so it knows what
ODS it is working with and a few other things. These could be
suppressed if you supplied the information manually. Then, you could
have your much faster operations and a significantly faster connect
time as well. >>>
I think these conections times are acceptable.
Best Regards,
Carlos Macao