Rajesh,

Are you actually returning all of your blob data, or just the
pointers, and getting the blob data on demand when you display it??

My database has 8k pages, I do not know the Server's installation.
They are a commercial site, so I "assume" they have plenty of memory
and space allocated to handle their clients. I have run my test app at
different times of the day and night with no noticable difference in
performance times. I also returned over a 35,000 row query, by
accident, of other data without blobs and it was very fast. So I think
the problems is with Blob fields and the dbExpress drivers for
Interbase/Firebird. Even tne native Interbase/Firebird components are
very slow??

Austin



--- In firebird-support@yahoogroups.com, Rajesh Punjabi <rajesh@i...>
wrote:

>
> Dear Austin,
>
> Here are my own benchmarks.
>
> Select Code, Name, Workdone from Candidates where Code <= 100;
> Connection time : 150 ms
> Query Opening Time : 30 ms
> Client Data Set Opening Time : 1.5 secs
>
> Select Code, Name from Candidates where Code <= 100;
> Connection time : 150 ms
> Query Opening Time : 30 ms
> Client Data Set Opening Time : 30 ms
>
> Select Code, Name, Workdone from Candidates where Code <= 1000;
> Connection time : 150 ms
> Query Opening Time : 30 ms
> Client Data Set Opening Time : 16 secs
>
> Select Code, Name from Candidates where Code <= 1000;
> Connection time : 150 ms
> Query Opening Time : 30 ms
> Client Data Set Opening Time : 35 ms
>
> I display the data in the standard DBControlGrid. Not in any third

party

> controls.
>
> Yes there is a slowdown in the system with multiple blob fetches. But
> you must remember here that I am working with blobs that are about

2000+

> chars at any time. Your performance drop does not however seem

justified

> given that you have lesser chars in each blob.
>
> Is your server using 8 KB page size ? Do you have enuf swap space on

the

> server ? What is your virtual memory setting. Maybe you could shift

from

> blobs to say Varchar(2000) or something like that.
>
> I wonder what is the optimization that MySQL does which FB is not doing
> while fetching blobs. Must be in the driver.
>
> There is a blob size property with the connection strings that has been
> left to the default value of -1 in my testing. What effect does

changing

> that have ? Any idea ?
>
> Regards,
>
>
> RP
>
> ggroper wrote:
>
> >Hi Rajesh,
> >
> >My test app is a simple slect records from a single table with a
> >criteria that returns 35 records from 66,000. I displayed the text in
> >an info power grid so the Blob fields display in the grid. My app
> >needs to do this so the user can scroll and review the memo fields. I
> >can not change the design so that it to only return on row at a time.
> >The users will kill.
> >
> >Below are my test results to a remote host from last night. I am
> >shocked at mySQL performance, it looks like the solution but I do not
> >want to use it??
> >
> >
> > With Blob Fields/Without Blob Fields
> >mySQL Database with Borland db Express Driver: 0.79/0.64
> >FIB PLus to a Client Data Set 8.72/1.54
> >dbExpress using Borland's IB driver 30.1/1.18
> >dbExpress using 3rd party FB driver 29.5/1.12
> >dbExpress using OLEdbExpress(with FB's ODBC driver) 7.9/1.65
> >
> >Yet all tests are nearly subsecond on a local database connection. And
> >all tests, except FIBPlus, are using the same dbExpress components??
> >mySQL just blows away Firebird, why????
> >
> >Austin
> >
> >