Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 7 of 7 total
Thread Speedup over remote session via VPN
Fri, May 1 2015 1:22 PMPermanent Link

Robert D. Smith

Avatar

I have a master/detail database located on a Linux Samba server.  They are not being hosted by a DBISAM server, however.  Just on a network share.

When accessing my app locally on the network, there are no issues.

However, when I attempt to access the tables over VPN from home, it slows down DRAMATICALLY.  To the point, where the apps timeout or error out.

The detail database is a little large at around 332Mb.

I have not set any caching up in my app, and I was thinking this might help with the issue, however, I have never actually done this before.  I was wondering if anyone can give me some tips on what property values to set and in which component.

Essentially, the master/detail relationship of the database layout is:

Master:
Timestamp

Detail:
Timestamp
Other fields relating to the detail table.

Can anyone offer any suggestions?

Thanks in advance!
Fri, May 1 2015 1:37 PMPermanent Link

Robert D. Smith

Avatar

Robert D. Smith wrote:

I have a master/detail database located on a Linux Samba server.  They are not being hosted by a DBISAM server, however.  Just on a network share.

When accessing my app locally on the network, there are no issues.

However, when I attempt to access the tables over VPN from home, it slows down DRAMATICALLY.  To the point, where the apps timeout or error out.

The detail database is a little large at around 332Mb.

I have not set any caching up in my app, and I was thinking this might help with the issue, however, I have never actually done this before.  I was wondering if anyone can give me some tips on what property values to set and in which component.  Or maybe caching isn't what I want.  Maybe it's some form of paging (limiting the number of records to retrieve at a time)?

Essentially, the master/detail relationship of the database layout is:

Master:
Timestamp

Detail:
Timestamp
Other fields relating to the detail table.

Can anyone offer any suggestions?

Thanks in advance!
Fri, May 1 2015 8:51 PMPermanent Link

Raul

Team Elevate Team Elevate

On 5/1/2015 1:37 PM, Robert D. Smith wrote:
> I have a master/detail database located on a Linux Samba server.  They are not being hosted by a DBISAM server, however.  Just on a network share.
> When accessing my app locally on the network, there are no issues.
> However, when I attempt to access the tables over VPN from home, it slows down DRAMATICALLY.  To the point, where the apps timeout or error out.

It's likely not just due to the VPN but the overall Internet connection
(i'm assuming you're accessing this over Internet when you say from home
and VPN) since you are adding "significant" delay into every request
(i.e. say 50ms which means that every 20 trips to server would mean
extra 1 sec of just waiting data to travel).


> The detail database is a little large at around 332Mb.

Since you're using local data access all of that 332Mb needs to be read
every time (since engine needs the whole table for any filtering) -
there will be some engine caching and some OS caching but probably
fairly large amount of data has to be transferred all the time.


> I have not set any caching up in my app, and I was thinking this might help with the issue, however, I have never actually done this before.  I was wondering if anyone can give me some tips on what property values to set and in which component.  Or maybe caching isn't what I want.  Maybe it's some form of paging (limiting the number of records to retrieve at a time)?

You cannot "limit" with file server setup - your engine needs the whole
table since all filter/processing has to take place on your pc where the
dbisam engine runs (in your app).

You are on the right track with paging and caching in a sense of forcing
engine to read multiple records at a time (instead of 1 i believe is
default per trip) whenever it reads data thus reducing number of trips
to the table/database.

See LocalReadSize property (and buffer parameters linked in there also):
http://www.elevatesoft.com/manual?action=viewprop&id=dbisam4&product=rsdelphiwin32&version=XE7&comp=TDBISAMDataSet&prop=LocalReadSize


You'd be setting this for query/table object.


You can likely make it bit faster by trying out different settings but
i'd be surprised if it will ever be fast enough to be truly useable.

My suggestion would be to run dbsrvr somewhere in the office (dbsrvr
does have a linux version so that might work right on the server or
alternatively run windows dbsrvr on another PC that's in the office).

Then filtering would be done on server and only final datasets would be
sent to you over VPN (and if you end up using this then check out the
RemoteReadSize property that does the "paging" for remote connections).

Raul
Fri, May 1 2015 9:31 PMPermanent Link

Raul

Team Elevate Team Elevate

On 5/1/2015 8:51 PM, Raul wrote:
> Since you're using local data access all of that 332Mb needs to be read
> every time (since engine needs the whole table for any filtering) -
> there will be some engine caching and some OS caching but probably
> fairly large amount of data has to be transferred all the time.

As i was reading this i realized there might be some filtering possible
 as long as your tables have proper indexes (in your case i think
Timestamp on detail table). It's possible that only part of the detail
table needs to be returned (this assumes index allows dbisam to pick the
right records and then smb allows retrieval of sections of the file only
- not sure if either is true but worth a try).

The other suggestion i had was that if you can use exclusive table
access while working over vpn then that might help  as well - it would
of course prevent anybody else from accessing tables but ought to make
caching and such easier (again theoretically).

Raul
Sat, May 2 2015 2:45 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Robert


I'm a bit nastier than Raul - give up - you're wasting your time. F/S (which I love) relies on a fast connection (the ideal one is on your local disk) since it transmits lots of data over the wire. Even c/s may not be fast enough to make the thing workable depending on the speed of the connection you have and the routing.

I have had f/s running on slow LANs (remember coax anyone) but at least the connection didn't keep dropping. My first attempts to use a wireless LAN failed with c/s because the connection dropped every now and again. That's something that can happen with the internet and it only takes a few ms outage for f/s to collapse. C/S would recover. If you want to move to c/s you may need to do a bit of rewriting of the app.

What I'd look at is one of the remote access systems (I don't know if there's something like Citrix for Linux). If there's a spare PC that can be left turned on in the office you could use something like TeamViewer. I use that to help my wife's aging aunt in Spain from Scotland. Not brilliant but very usable once I've made her sit on her hands so she can't be "helpful"

Roy Lambert
Thu, May 7 2015 7:17 AMPermanent Link

Robert D. Smith

Avatar

Roy Lambert wrote:

Robert


I'm a bit nastier than Raul - give up - you're wasting your time. F/S (which I love) relies on a fast connection (the ideal one is on your local disk) since it transmits lots of data over the wire. Even c/s may not be fast enough to make the thing workable depending on the speed of the connection you have and the routing.

I have had f/s running on slow LANs (remember coax anyone) but at least the connection didn't keep dropping. My first attempts to use a wireless LAN failed with c/s because the connection dropped every now and again. That's something that can happen with the internet and it only takes a few ms outage for f/s to collapse. C/S would recover. If you want to move to c/s you may need to do a bit of rewriting of the app.

What I'd look at is one of the remote access systems (I don't know if there's something like Citrix for Linux). If there's a spare PC that can be left turned on in the office you could use something like TeamViewer. I use that to help my wife's aging aunt in Spain from Scotland. Not brilliant but very usable once I've made her sit on her hands so she can't be "helpful"

Roy Lambert

That's what I was afraid of.  We used to use TeamViewer, but just upgraded this user to a notebook, so her desktop is being repurposed, so there's nothing to dial into now.  I'll check around to see if I can find a spare PC for this.

Thanks
Sun, May 24 2015 4:28 AMPermanent Link

Colin Wood

VirtualTec P/L

If you are going down the path of Remoting in to a PC, you may want to look at http://www.thinstuff.com/products/
It enables multiple connections for users to the 1 PC (doesn't need to be a server) and gives good access to your remote app via a Remote Desktop Connecting app that comes windows.  I've used it very successfully with around 10 concurrent users.  Since only the screen is updated, with no database data being passed backward and forward, it provides a good service without much of a dollar outlay.  Not sure that Bill Gates will be too happy with this method though, as it seems to bypass all multi-user licensing issues AFAIK.
Colin
Image