Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 7 of 7 total |
Speedup over remote session via VPN |
Fri, May 1 2015 1:22 PM | Permanent Link |
Robert D. Smith | 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 PM | Permanent Link |
Robert D. Smith | 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 PM | Permanent Link |
Raul 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 PM | Permanent Link |
Raul 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent Link |
Robert D. Smith | 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 AM | Permanent 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 |
This web page was last updated on Saturday, April 27, 2024 at 08:52 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |