I have a client who has just opened a branch office in another city.  I need to develop an application that will need to be accessed via the LAN in the main office and also from the branch office via a public internet broadband connection (not a dedicated communications WAN).

Although I can be fairly selective about the volume of data included in the queries, there are times when the application will need to show several thousand header records in a grid.  In most cases, I can restrict most normal queries to a couple of hundred records or less.

Since I have options about the hardware to be installed, I could have a dedicated server created that could host several dozen remote desktop sessions.  This server would contain SSD drives and as much memory as required.  Remote clients could then initiate remote desktop sessions and run the application on the head office LAN as a "local" machine.

Alternatively, each remote client could run the application and rely on a connection to a ElevateDB server running at the head office via the public broadband internet connection.  I assume there are techniques for dealing with firewalls although I haven't looked at this issue yet - ie.   several clients running on a branch LAN and connecting to an ElevateDB server on a remote Lan.

My question is: what would be the preferred approach in terms of performance?  Logic tells me that keeping all the data on the local LAN and just managing the remote desktop sessions would yield the better performance since only screen images and keystrokes are transmitted over the broadband connection.  On the other hand, ElevateDB's compression and caching techniques are also designed to minimize network load.

If anyone has any hard experience with this question I would appreciate your advice.

Thanks,
... Norm Clark

Norman,

How current does the main office data have to be at the branch office? Can it be 5 minutes old? 15 minutes? In other words, how often does it have to be refreshed?

Barry

Barry wrote:
"
How current does the main office data have to be at the branch office? Can it be 5 minutes old? 15 minutes? In other words, how often does it have to be refreshed?

Barry
"

It is possible for the branch office staff to be working on some of the same records as the head office staff so the data must be as "real-time" as possible.  In that sense, the data must be refreshed as soon as it changes.
... Norm

On 10/11/2012 3:40 PM, Norman Clark wrote:
> My question is: what would be the preferred approach in terms of performance?  Logic tells me that keeping all the data on the local LAN and just managing the remote desktop sessions would yield the better performance since only screen images and keystrokes are transmitted over the broadband connection.  On the other hand, ElevateDB's compression and caching techniques are also designed to minimize network load.

Our preference is remote desktop option - basically all remote users
connecting back to head office and running app "locally" on the server.
Nice side effect is that should they have a connection problem they can
usually just reconnect to their old session and continue where they were.

Don't know your app but in our case there can be multiple DB requests
even for same screens so latency starts to matter more than bandwidth.
Also if you use data bound controls those might get tricky over WAN as well.

Raul

Norman,

I have a case just like yours.
They were using remote desktop sessions over Internet *before* EDB, to connect from the branch office to the headquarters server. Currently, we completely dropped that solution and our new application offers them a mixed solution:

-There is an EDB server running in each one of the offices, with it's own copy of the database, and the databases are automatically replicated every 6 hours (in fact its configurable, it could be every hour or so); this allows them to keep working even if Internet fails. Also, an administrator can "force" a replication at any time.

-In addition, when the application starts they are given the choice to connect to the headquarters EDB server (over the Internet) instead of the local EDB server and work on-line.

This design also allows them to take a laptop with the application installed, and connect to any one of the servers at any time from any place over the Internet; the difference is they don't have a local copy of the database in their laptops, they can only connect to one of the EDB servers.
There is no need for additional software, like remote desktop clients or terminal services licenses, its all EDB .

--
Fernando Dias
[Team Elevate]

Norman,

<< My question is: what would be the preferred approach in terms of
performance?  Logic tells me that keeping all the data on the local LAN and
just managing the remote desktop sessions would yield the better performance
since only screen images and keystrokes are transmitted over the broadband
connection.  On the other hand, ElevateDB's compression and caching
techniques are also designed to minimize network load. >>

Here's the rundown on using EDB over a WAN:

1) You have to be careful about the *number* of requests from the
client/remote session due to the higher network latency on each request.
Things like lookup fields that cause transparent record pointer movement in
other datasets are particularly well-known performance killers.  However,
the good thing is that it's very easy with the TEDBSession.OnRemoteTrace
event handler to determine where these types of performance killers lurk:

http://www.elevatesoft.com/manual?action=viewevent&id=edb2&product=delphi&version=7&comp=TEDBSession&event=OnRemoteTrace

Normally, I recommend that you simply pop a "stay on top" form into your
application that has a single TMemo on it that you can dump the trace record
to with a simple Lines.Add() call.   Then, show the form when you have the
TEDBSession.RemoteTrace property turned on, and keep it hidden when you
don't.  This way you can use your application and see things progress in
real-time.  It's a very valuable tool for diagnostics, and unfortunately one
that EDB cannot automatically provide without pulling in the Forms unit,
etc. and bloating the codebase.

In general, the bottom line with WAN usage is: keep the number of requests
small, and the size of the request responses as large as possible.  With
datasets, use the RemoteReadSize property liberally:

http://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=delphi&version=7&comp=TEDBDataSet&prop=RemoteReadSize

Setting it to 100-500 is usually a good number, depending upon the row size.
Please keep in mind that warnings about memory consumption in the manuals
are from when EDB was created a few years ago, and client memory is fairly
plentiful now, so reading thousands of rows at a time, especially with the
TEDBSession.RemoteCompression property set to 6 (turned on, default), is
something that isn't out of the question.

2) If your application is keyboard/mouse-intensive, then remote desktop
solutions will suffer in comparison to using EDB directly over the WAN for
the same reason as above - they're "chatty" and incur the network latency on
every keystroke/mouse movement (or almost every keystroke/mouse movement,
remote desktop may be optimized to send multiple events at a time).  This is
especially true once you've optimized out any issues noted above.  With EDB
directly on the WAN, once the data is retrieved from the EDB Server,
everything is local again in the client memory.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com