Hi,

At April 11, 2005, 10:19, Pete Bray wrote:

>> However, for my test app returning 35 records in less than 2 seconds
>> with NO Blobs and 32 seconds with blobs conataing a total 3,209 plain
>> text characters does not make sense?? Especially, when all get
>> returned very fast on a local connection.
>>
>> Does anyone have any ideas??

> how 'asymetric' is your wan connection at the weakest point. i didn't get
> the expected performance benefit moving from varchar to blob (this was pre
> firebird 1.5 which now has over the wire compression for varchar)

There no compression for varchar, it simply doesn't transmit the
trailing blanks. FB 1.0x and prior transferred varchars full length
including trailing blanks(i.e.: if varchar(120), it transferred 120
characters).

> and i'm
> pretty sure it was due to the increase in packet handshaking required to get
> a blob (they will be so many people on this list better able to comment on
> this but i think that a record is returned containing the id of the blob and
> then the client goes and requests the actual blob using the id).

This is true.

> if you have
> a slow upstream link this would slow down the data download because
> presumably each blob has to be requested.

It might have to do with how blobs are actually transferred. Each
segment might be transferred individually, in separate packets, and
all of the segment, not just to used portion.

There is room for improvement for the wire protocol and it is supposed
to be reviewed, or most likely a new one created, for FB 3.0.

--
Best regards,
Daniel Rail
Senior Software Developer
ACCRA Consultants Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)