Hi Austin,

I get all the actual data and not the pointers.

But I guess this is pretty much the benchmark; fact is that FB blobs &
dbXpress do not seem to be a killer combo :-)

What is the size of your database file. Is your db split into multiple
files ? Try that if you have a large DB. My feeling is that there is
something in your program or server settings that is problematic. I am
unable to however pin point it. for just 500 chars kind of data your
performance benchmark is pathetically slow.

If you are storing small textual information in the blob just try the
varchar(1000) kind of fields which will make life comfortable I guess.
Nothing else to add from my end.

Let me know if you want to run more tests at my end. I have my own
production RH8 Linux server with 2 GB physical RAM where I can do some
custom testing for you with volume data if you feel the need for any
more benchmarks.

Regards,


RP

ggroper wrote:

>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
>>
>>