Remote Access Slow

[owenchaka]

Hi am a new bee
I developed a desktop application and the database is stored locally on our server. Each user accesses the database using
Runtime, has a shadow database on their C: drive and access the server through a LAN. This works well locally.

Our remote users are currently accessing the database through Windows Remote Desktop. shadow database for each user had been set up on their individual user profiles on the server. This is slow and is not a long term solution.

Does Alpha Five have a specific solution for remote connectivity through the public network; if not do you have any suggestions?

[Ted Giles]

Re: Remote Access Slow

Have you looked at VPN or Citrix Presentation Server?

[martinwcole]

Re: Remote Access Slow

How many remote access users do you have at any point in time

Normally, you would not shadow a remote user - they would just run the app on the server from the runtime

the better the server and broadband speed the better the performance

I use T/S for remote users. Also, are you still on 2003 or have you moved up to 2008?

[owenchaka]

Re: Remote Access Slow

Am using TS 2008 for remote user, am not sure which one is the best for remote access Citrix or Microsoft T/S in terms of speed

[Ted Giles]

Re: Remote Access Slow

Owenchaka
I think I had to budget about �250 per seat for Citrix.
This included the IS Install costs. But it was transferrable.
You could probably get free 30 day trial if you asked a reseller.

Martin, why would you not shadow a remote user? Surely the line traffic would be less?

[martinwcole]

Re: Remote Access Slow

If, by shadow, we mean to use the runtime on a remote workstation, and shadow back to the server, then we are talking about a WAN, or wide area network. This will be like pouring dark mollasses on a cold morning. A tremendous amount of data has to pass back and forth from the server to the workstation on a shadowed database.

At the 'home office,' people will sometimes set up 2 or more servers - and shadow from server 1 to server 2, and the remote users come in to the server via Citrix or T/S. So far I've never need to use this approach, but it is for handling a lot of concurrent users.

If, by shadow, we mean to create a shadow on the server itself, which can be done, then there would be wasted resources. If you are already on the server, as from T/S or Citrix, then there is no reason to make a shadow. They are designed to permit multiple sessions.

As for which is the fastest - T/S or Citrix - I don't know. I have only ever worked with T/S. The new T/S with server 2008 R2 is very nice, and makes for easy setting up of local devices that can communicate, like printers, USB devices, etc. From what I've read and the people I have talked to, Citrix is more sophisticated than T/S, but I doubt it is any faster. T/S is about 80 US$ per seat, purchased in lots of 5.

[Ted Giles]

Re: Remote Access Slow

Now I'm confused. Network Optimisation suggests that the only actual traffic will be the data.
Are we talking about 2 different things?
Please excuse my ignorance on this matter, but until I read your comment, I would have distributed the R/time and App, and set up Network Optimisation on a WAN, just as I would have in a LAN.
So it's better to run an app in a WAN environment direct on the server?
Might save me a bit of embarrassment!

[martinwcole]

Re: Remote Access Slow

Yes, using a WAN, only the data will travel back and forth, but the AMOUNT of data that travels is humongous (sp?) and the performance will be poor. At least if you are using dbf's.

If you did everything but maybe your menus using xdialog screens, and controlled the number of records available to the user, you could increase performance (reduce the amount of data)

But otherwise, I would use T/S or similar. At least, if I had more than one person who needed remote access. And then I would just have them use Logmein or similar.

If you have a situation where you can test it, using a WAN, you can try it. If the app is simple, like a book for your grandmother to store her recipes in, and have only a few records, it would work, But if you have a fullblown business app, and they will have a lot of records after a while, it will be very slow.

[Ted Giles]

Re: Remote Access Slow

Understood Martin, thank you.
I now see where a 900k record lookup would slow things down.
Just call me Homer.

[owenchaka]

Re: Remote Access Slow

Thanks guys, i have learned some valuable infor thanks

[peterg000]

Re: Remote Access Slow

Generally Remote access using TS should be fast since all that is being sent back to the user is screen paints ... all data(dbf) work is done on remote server. The real issue is on the server and how you access the DBFs .... if your data is local on the drive of the server, performance should be great ..... if your data is being sent across the network(shadowed or not) in anyway, there is a performance hit ... the performance hit depends on your application and the size of your data, but in my opinion, the app over time becomes unusable.

Scenarios .....
local user on server ----> runs rt(runtime) app on server and directly accessing data local on server ----> good performance
local user on server ----> runs rt app on server and indirectly accessing data on shared drive (shadow or not) ----> poor performance to terrible performance
remote user on client machine ----> runs rt app on client and indirectly accesses data from server using shared drive (shadow or not) ----> terrible performance
remote user on client machine ----> RDPs into terminal server on server and runs rt app and directly accesses data local on server ----> good performance
remote user on client machine ----> RDPs into terminal server(server) and runs rt app and indirectly accesses data from shared drive (shadow or not) ----> poor performance to terrible performance

Bottom line, if you have to pass DBF data over the network for an app that has a sizable amount of data .... you will not be happy with performance. And for those that say shadowing helps ... it does nothing for the actually data itself.

choices ....
Terminal services
Citrix
TS-Plus
Others .. do google search .. :)

Hope that helps ....

Glenn

[csda1]

Re: Remote Access Slow

Speed has almost nothing to do with the data transfer. 900k data over the internet/ WAN takes no significant time (if not on dial-up), and the latency of the data has no significant effect to any other client.

However, slow access does occur due to record locking being attempted from a WAN. One WAN client not on a virtual computer on the LAN, accessing a shared table, will slow every client computer to a crawl (approximately 2000 times slower by my estimates) while the WAN client is reading or writing any records. Accessing 1 record, may be OK. However, accessing 1 parent record in a 1 to many set may cause many locks for the children, and doing reports and operations are repeating it for every record being accessed.

See Record Locking 101 Tips on my web site.

[peterg000]

Re: Remote Access Slow

Ira .... a lot goes into performance, and speed of the network is just one of the variables .... but it is definitely one of the variables and shouldn't be ignored. With that said, its kinda irrelevant ... people just want the truth about DBFs and what the actual limit is ... my previous thread spells it out in the most simplest terms. If you keep your data access local, performance will remain good for large tables, but I would say if your accessing over the network in any way and your tables get to between 50k - 100k records, performance will not be great (but doable) ... anything over 100k, you will not love the experience and should probably be moving to a real database such as MySQL.

Glenn

P.S. Great write up on record locking .... thanks!!

[Ted Giles]

Re: Remote Access Slow

Ira, many thanks. Link now on my Desktop.
BTW. The 900k was records, not just data. They are UK CQC records so quite big.
Seems like any WAN apps need to be run under SQL, so does an Alpha Active Link to an SQL backend over a WAN work like greased lightning?

[csda1]

Re: Remote Access Slow

Hi Glenn,

Ira .... a lot goes into performance, and speed of the network is just one of the variables .... but it is definitely one of the variables and shouldn't be ignored.

Actually, when used over any network that has a very long latency (2000 to 1 for typical internet usage) the locks are what take the time as each lock must return a response to the client before the next one can be started. If you do 10 locks at, with say a latency of .5 seconds over the internet, that means it takes 5 seconds for just the locks. The data itself does not really have a latency issue and does not hold up other clients. Just try it over the internet and you will see whether a record is 50 bytes or 4k bytes (whatever the maximum size of a record can be), it will take almost the identical time. Only when done on a local area network does data transfer time start to make a difference (although small).

To compare it, just copy a 100 Meg file from a network drive on a LAN. Now do the same with a copy records operation (which batches the file locks a bit so it is still more efficient than say a browse through records 1 at a time) to a local table with the same amount of data. Repeat the process over a WAN connection

This will give you the comparative speeds of data transfer to locking with data transfer. On a WAN, the data transfer time is an extremely small component of time compared to the locking.

That basically means that if you are not running the DBF file (and this applies to Access, Filemaker Pro and any other non-True Client Server file) from the LAN, either directly or via Citrix, T/S, PC Anywhere, VNC, LogMeIn, Team Viewer or any other remote viewing/control program, you will find intolerable operation.

... but I would say if your accessing over the network in any way and your tables get to between 50k - 100k records, performance will not be great (but doable) ... anything over 100k, you will not love the experience and should probably be moving to a real database such as MySQL.

The number of actual records in a DBF table file is actually unimportant, and only the number of records you access makes a difference. If not using good techniques like LQO and carefully designed links and indexes and coding, you can be slow with 10k records. Good techniques will allow good usage up to 1M+ records and 100+ concurrent users on typical 1 Gig LANs.

SQL has it's own speed penalties, mostly with the limitations of the server speed versus the quantity and type of requests. Load balancing on multiple servers will help there, but bad techniques will still bring it to being slow. However, SQL does eliminate the locking issues, particularly over WAN (then again, so does Citrix and the like).


Hi Ted,

Seems like any WAN apps need to be run under SQL, so does an Alpha Active Link to an SQL backend over a WAN work like greased lightning?

It doesn't have to be run under SQL, but you can't have the locks happening over the WAN (Hence why Citrix exists). But SQL can be done or appear fast if you limit the data over the network and/or prefetch data while the user is viewing other data. The more you can eliminate traffic over the WAN (by using client side validation, etc), the faster it will be to that client. But no matter what, the SQL backend will not be holding up other users (until you max out on server speed). So greased lightning, probably not. Acceptably quick, yes.