Have you tried sniffing the packets and looking for the differences. I have
had to make IB/FB work over slow (64kbit) and got reasonable responses if
coded to cater for it.

From my research there are two factors, bandwidth & latency & to be honest
the real killer can be latency.

If IB uses the same volume of data to do the same job, but actually has
twice as many synchronous interactions, then performance will go through the
floor.

We had a site that took about .25s (from memory) to do a round trip from
client to server, they kept upping the size of the pipe, but the trip time
wasn't considered. Performance didn't improve with the extra $$$ for the
leased lines. Basically the way they wrote the app, it wasn't responsive
until 22 interactions with the server had occured - it was SLOW. After
doing a code review I suggested:
a) mutli-threading
b) caching
c) better transaction control / preparation of queries
d) modify parts of the architecture.

No idea what they did, but I know they could have got a time to live from 10
seconds -> 2 seconds.

As always from me, no answers, just considerations...

JAC.


""Jason Frey"" <jason_frey@...> wrote in message
news:001a01c1f929$a24e7270$c6520244@cx706785b...

> Is it feasible to use IB/FB over a slow link? When I mean feasible, I

mean

> usable, not "is it possible".