In this case, it is probably fine to keep them in the GDB. It would be too
much hassle to manage them outside of it to make it worth it.

I agree with you that the wire protocol of InterBase is in need of major
revisions. I started some threads a while back in IB-Architect suggesting
such and I was nearly beheaded for suggesting it...

Especially in the case of whitespace omission. There is no need to
whitespace to cross the wire, I don't care what compression algorithms are
being used. First get rid of what isn't necessary, then compress if you
like.

I think it is near time to put my head on the block again.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "ing. Thijs Kuperus" <thijs@...>
To: <IBObjects@egroups.com>
Sent: Wednesday, January 24, 2001 9:55 AM
Subject: RE: [IBO] Performance (as a result of blob inserts)


> Indeed.. I didn't notice any change either (when changing segment size).
> However, like I said before, I noticed an awfull lot of packets going over
> and back with very little data.
>
> I hope not that's the best optimization the wire protocol can come up with
> :-)
>
> Anyway.. the blob's I'm storing aren't really that big or so.. It's mainly
> HTML templates and variable user input.. so I figure the average on those
> blobs stays under 2k. It's just that when I used the VarChar type, I read
> somewhere that the server expands the varchar with spaces and then
transfers
> the whole thing.. I read that IBO then throws those spaces away again...
> seems to me to be unnecessary transfer over the line.. I think/thought
blobs
> were more efficient... I could be wrong though..
>
> -----Oorspronkelijk bericht-----
> Van: Jason Wharton [mailto:jwharton@...]
> Verzonden: woensdag 24 januari 2001 17:28
> Aan: IBObjects@egroups.com
> Onderwerp: Re: [IBO] Performance (as a result of blob inserts)
>
>
> IBO ignores the segment size. I slam it up to 64Kb. Segments were an
> artifact of living at a time when a system may not have had a spare 32K
> laying around to buffer the contents of a large BLOB. Nowadays, 64Kb is
not
> a big deal...
>
> I am assuming that the wire protocol will know how to most efficiently
> package and transport the BLOB data no matter what the size of the
segments
> are declared as. I could be wrong here but I haven't noticed any
performance
> degradations in so doing.
>
> FWIW,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
> ----- Original Message -----
> From: "Lucas Franzen" <luc@...>
> To: <IBObjects@egroups.com>
> Sent: Wednesday, January 24, 2001 4:20 AM
> Subject: Re: [IBO] Performance (as a result of blob inserts)
>
>
> >
> >
> > "ing. Thijs Kuperus" schrieb:
> > >
> > > Hello there,
> > >
> > > I keep shooting questions!
> > >
> > > Another one:
> > >
> > > What is the minimum line speed over which i can reasonably run IBO and
> > > Interbase on a remote server? Perhaps my situation to illustrate:
> > >
> > > I have a server running on the internet. I connect to my ISP with
single
> > > ISDN (64KBit/s). The RTT (Round Trip Time) is between 60 and 200 ms...
> Now I
> > > noticed that for instance a blob insert can't go above 4 inserts a
sec!
> Upon
> > > inspecting the line stats, I saw that for about each 80 bytes a packet
> is
> > > send... considering a TCP/IP overhead of about 50 bytes that means a
> VERY
> > > bad optimized connection.. on a LAN everything works just great, coz
the
> RTT
> > > is very low, but when we're on the internet, those small packets
really
> hit
> > > the performance hard...
> > >
> > > So... what do the experts say about this?
> >
> > It seems that you haven't defined the segment size for your blobs - if
> > you don't do so then the default sgement size is 80.
> >
> > You can try to create another segment size and see which performs best.
> >
> > for example:
> > create domain T_BLOB_1024 as BLOB SEGMENT SIZE 1024;
> >
> > Have a look in the Data Definiton Reference, page 71 ff. (DATADEF.PDF
> > for IB 5.6)
> >
> > Let me know, if this will improve performance.
> >
> > Regrads
> > Luc.
> >
> >
> >
>
>
>
>
>
>
>
>