A lot of database applications exist that have not been engineered
for good WAN-behaviour. The problem as vbarajas describes with
rpc-based calls, is that a lot of synchronisation takes place in
the client-server communication. This results in the application
getting a "rtt-multiplicator" ranging typically between 1 and 50,
or even higher. This already impacts applications with a WAN-
distance between 10-100ms noticably.
One problem that many application developers don't see is that
the client-server paradigm is just a special, restricted case
of distributed computing. Whole studies have been made of
distributed databases and their optimisation, but I haven't
seen those applied to the two-host (client,server) model in
practice.
Good practice would involve:
- caching frequently consulted small-to-intermediate tables.
- bulk-validation and/or server based validation.
Unfortunately, the typical application developer will use
specific GUI toolkits for designing forms, which in turn
are layered over platform-specific network-abstractions
which are designed to hide the network details (netware,
tcp/ip, etc). This is an architectural choice, and is
typically not decided on by the individual developer(s).
And there's the rub: Hiding implementation details can be
a good design methodology. It's not when it will also
hide the timing-dependencies.
[email protected], speaking for myself.
In response to [email protected]:
>
> I have also heard "anecdotes and innuendo" regarding this topic for both
>Oracle and SAP.
>
> I'm guessing here, but from my experience with setting up applications
>and
>software that utilize RPC's (Remote Procedure Calls) this could be in
>reference
>to the normal "tweaking" of networking parameters that must be done for a
>specific network environment (normally a LAN). Applications using RPCs in a
>complex networking environment can be adversely affected by "ill behaved"
>network traffic (What is ill behaved depends on the application and
>environment).
>
> I would be very interested to hear specific instances of application
>"problems" that can be traced to the network environment (or specifically
>transport delay)
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:33 EST