Re: SQL*NET over a Wide Area Network

You are simply running into latency over the link. In a WAN each request incurs the link latency (lag time accumulated as you traverse the WAN) there is very little you can do about this when small packets are involved. If the volume of the data is large, simply more bandwidth fixes it. In the WAN all you can do is optimize/reduce latency.

One thing you might try to do is minimize the number of sql requests as each incurrs the latency as the request is issued and recieved. This is ugly but works: if you have to retrieve say 5 lookup/validation tables, each with an ID and description, then turn it into 1 query using unions and decouple at the client end. This would elimiate 4 x Wan latency. Not pretty but it does work. This solution does not impact the local client, at least visibly if the decoupling is done well.

Steve Bellamy <100074.1541_at_compuserve.com> wrote in message <01be1d8a$9682cf00$351bd3d4_at_adhoc>...
>The application that I'm working on operates fine over a LAN
>(even old 4 or10 mbps links), but we are having performance
>problems at locations connecting over slow WAN or dial up links.
>The 64K links seem to be able to carry the necessary bandwidth,
>but not the volumn of small (<2K) packets generated by SQL*NET.
>Where possible I've tuned the OO4O dynaset options to
>maximise the data retrieved by each fetch, but the application
>generates many selects to get unrelated data from various
>tables.
>For example, one form makes five independant selects which
>each return 0-20 rows. It takes 2 seconds to load the form
>when the data is retrieved over the LAN, but 5 seconds over the WAN.
>
>Any ideas would be appreciated!
>
>Steve Bellamy
Received on Wed Dec 02 1998 - 05:40:24 CET