Jason,

I did catch the reference to "legacy" system, but since Art was
enquiring about adding some IBObjects functionality I took this to mean
that some modifications/enhancements are possible, but that he didn't
want to significantly re-engineer the overall product (aka my
middle-tier suggestion).

To my mind adding a SP to a database for the task that he outlined,
seemed a reasonable solution.


Sean

> -----Original Message-----
> From: Jason Wharton [mailto:jwharton@...]
> Sent: Thursday, January 25, 2001 12:20 AM
> To: ib-support@egroups.com
> Subject: Re: [ib-support] excessive network traffic [LONG]
>
>
> Sean,
>
> Seems that the phrase "supporting legacy systems" rules out
> both of your
> suggestions. While your suggestions are good for someone in a
> position to
> implement them, I'd like to see his questions directly
> answered. This topic
> interests me quite a bit.
>
> > > My point (and I do have one!) and questions are:
> > >
> > > a. This traffic seems excessive. Do you agree?
>
> If I knew what to compare it to I could answer that.
> Considering what you
> are asking for it does seem excessive though.
>
> > > b. Where does it originate: bde? gds32? tcp/ip?
>
> Most likely the BDE.
>
> > > c. Would I get less traffic if I switched to IBObjects?
>
> You could take more control so the answer is yes but probably
> not without a
> little bit of work.
>
> > > d. How can I reduce it?
>
> Try the BDE to IBO quick conversion and see what happens.
> Shouldn't take too
> long to give it a shot since IBO has the TDataset based
> components which
> emulate the BDE ones.
>
> HTH,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
> ----- Original Message -----
> From: "Leyne, Sean" <InterbaseSupport@...>
> To: <ib-support@egroups.com>
> Sent: Wednesday, January 24, 2001 9:01 PM
> Subject: RE: [ib-support] excessive network traffic [LONG]
>
>
> > Art,
> >
> > Why don't you create a SP which does all your tests and
> then returns a
> > "configuration" string. That way all these tests could be done in a
> > single request.
> >
> > Now if your looking for even more significant performance
> improvements,
> > consider moving some of your application functions into a
> > middle-tier/application server. This will require some
> re-engineering,
> > but the benefits are considerable.
> >
> >
> > Sean
> >
> > > -----Original Message-----
> > > From: Art Metz [mailto:ametz@...]
> > > Sent: Wednesday, January 24, 2001 6:17 PM
> > > To: 'interbase@...'; 'ib-support@egroups.com'
> > > Cc: Todd Parker
> > > Subject: [ib-support] excessive network traffic [LONG]
> > >
> > >
> > > I am seeing what appears to be excessively many packets going
> > > between client
> > > and server. Details follow.
> > >
> > > I'm supporting a legacy app written with Delphi 3, BDE,
> > > InterBase 5.6. It
> > > needs to query a database created by a different app. It
> > > connects to a
> > > remote database over a modem using TCP/IP.
> > >
> > > For various reasons, different versions of App2 have
> > > different database
> > > schemas. App1 must support all the different versions. So,
> > > after opening
> > > the database, App1 queries some system tables to determine if
> > > certain fields
> > > and tables are present.
> > >
> > > The problem that I'm having is that the connection over a
> 56k modem is
> > > noticeably s-l-o-w. One of the network guys put a sniffer on
> > > the connection
> > > to determine just what the traffic was. Here are some
> examples of the
> > > dialog. I'm not bothering to uppercase names in literals.
> > >
> > > 1. // does a certain field exist?
> > > select rdb$field_name, rdb$relation_name from rdb$relations
> > > where (rdb$field_name = 'archive_24')
> > > and (rdb$relation_name = 'alarminfo')
> > >
> > > returns 1518+1518+1246+150 (=5950) bytes
> > >
> > > 2. // a query on a single-row table
> > > select realsite_id from alarminfo
> > >
> > > returns 1518+1518+1246 (=5800) bytes
> > >
> > > 3. // does a certain table exist?
> > > select * from rdb$relations where
> > > rdb$relation_name = 'mon1_camera'
> > >
> > > returns 1518+1518+1246 (=5800) bytes
> > >
> > > 4. // Is this query generated by the BDE?
> > > select rdb$owner_name, rdb$relation_name, rdb$system_flag,
> > > rdb$view_blr, rdb$relation_id from rdb$relations
> > > where rdb$relation_name = 'alarminfo'
> > >
> > > returns 1518+1518+1518+1246+170+
> > > 1518+1518+1518+1246+
> > > 1518+1518+1518+1450
> > > (=17774) bytes
> > >
> > > The "stuttering" of the value 1518 makes me wonder if the BDE
> > > (or possibly
> > > gds32) is attempting a query; timing out; and then
> > > re-sending. OTOH, the
> > > client doesn't resend. Could the server be looking for an ACK and
> > > re-sending if one doesn't come through?
> > >
> > > 5. I have other queries (you know, the kind that actually
> > > gets data to
> > > work with) that get sent up to four times in succession.
> > > This looks to be a
> > > true timeout/resend sequence.
> > >
> > > My point (and I do have one!) and questions are:
> > >
> > > a. This traffic seems excessive. Do you agree?
> > > b. Where does it originate: bde? gds32? tcp/ip?
> > > c. Would I get less traffic if I switched to IBObjects?
> > > d. How can I reduce it?
> > >
> > > Any suggestions or pointers will be greatly appreciated.
> > >
> > >
> > > Art Metz
> > > AMetz@...
> > >
> > > To unsubscribe from this group, send an email to:
> > > ib-support-unsubscribe@egroups.com
> > >
> > >
> > >
> >
> > To unsubscribe from this group, send an email to:
> > ib-support-unsubscribe@egroups.com
> >
> >
> >
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>