Disappointing VPN Performance

[fishtech]

Hi,

Remote:

Mac OSX 10.4 client VPN on DSL.

FMPro 8.5

Office:

Netopia 4622 on T1

FMPro Advanced 8.5

I'm in the early stages of testing mobile VPN connections to FMPro Server hosted at the office. My solution uses the spearation model with all graphics and layouts stored locally on the client.

I am seeing very slow performace. For example, a simple 'sort by last name' on 1000 records takes about 500 seconds, ie. only 2 records are sorted each second.

I had expected to see faster performance. Am I being unrealistic or is there a technical reason for the slow speeds? Do things speed up on the client with higher cache settings? Is there any performance tuning I can do?

Thanks,

b

[Søren Dyhr]

Couldn't the solution live outside the vpn, with a restriction on the IP number's which can access the hosted solution at all?

--sd

[Vaughan]

The over-all network speed is limited to the slowest link, which is the DSL: not particularly fast.

There could also be internal bottlenecks too.

"For example, a simple 'sort by last name' on 1000 records takes about 500 seconds"

The first time the sort is done, FMP has to download all the last name field data for all the records. This takes time; it's then cached. Which is why typically the first operation takes a while, but subsequent operations are much faster.

How long does it take for the find to be done a second time?

DSL isn't fast. At our organisation we have a building on a 4 Gb link and its performance is barely OK compared to the LAN in the main building. A DSL connection is a fraction of this speed, plus it's shared with the public so it's always busy.

Your options are to speed up the link, or change to something like Citrix.

[fishtech]

Thanks for the suggestions.

Søren... I have tried testing with the host outside of the VPN and it seems marginally faster.

Vaughn... Yes, if a find/sort is performed a second time the process is much faster. But the first time it is performed it is very slow. Plus, writing to the host is slow... simple 'replace' script steps take a long time.

I have tried using a much faster server box without success.

This is definitely a simple bandwidth bottleneck.

I guess I my expectations were higher. My users have Verizon USB wireless modems that get around 1.4 - 1.6 Mbps and I had hoped this would be enough for a reasonable FileMaker experience from their laptops on the road.

I don't think there are going to be any dramatic improvements from Verizon but I guess I could put some work into redesigning the interface for remote users to minimize the amount of data that is pushed about.

Thanks again,

ft

[Søren Dyhr]

We havn't talked much about the actual solution, a fair share of complaints about gear is unfortunately burried under an unconvenient or directly insufficient degree of normalization.

A pretty thorough desciption of the roundtrips in networked solution made by Debi Fuch and Steven Blackwell found on Ilyse Kazars webpage might reveal som do's and don't-es....

--sd

Edited November 13, 2008 by Guest

[normanicus]

Using VPN has no influence on how long FM takes to do things. (not absolutely true as the host machine has to use some of its CPU cycles to run the VPN server)

[normanicus]

Just realised you might not, as I had assumed, be using the VPN for screen sharing. If you are running FM on the local machine then it is indeed slow. Sorry for the false response.

[IdealData]

In my experience USB modems are slower then direct ethernet connections - there's a protocol conversion going off.

Your users "write" speed is controlled by their upload speed - on domestic connections this is typically around 1/8th to 1/10th their download speed, but may also be capped. In the UK a BT line is 8Mb down but only 400Kb up.

Do you need to host "in house"? If you host on the net then you will get more bandwidth but you still can't overcome the users "upload" restrictions.

[fishtech]

Thanks for the comment.

I placed the solution outside of our firewall for testing to eliminate the vpn. The speed increase was marginal.

ft.

[fishtech]

Yes, we do need to host in-house.

We are hosting on a T1, which is used as the main web connection for the company.

I'm off to look at lyse Kazar's page as suggested by Søren. Søren, is this the thread you are suggesting is appropriate reading?

http://network.datatude.net/viewtopic.php?f=36&t=102

ft.

[Søren Dyhr]

it is!

[Cheese Food Product]

It's not 100% important to point out, but available bandwidth is only part of the problem. Even if you upgraded the slowest link (DSL) to a faster connection (vDSL, cable, dedicated net, etc) -- you're also experiencing the classic effects of network latency. You have a distributed application, where the CLIENT must retrieve significant amounts of data during the sort from the SERVER across a high latency network (regardless of bandwidth). Most likely, the FM protocol that is responsible for the data retrieval is not network optimized -- i.e. it probably does not do bulk transfers, rather the CLIENT will request the first record-field in the sortkey, sent by the SERVER, ACKd by the client. Then the next record... SEND, ACK. Then the next record.

All this "ping pong" communication across the net consumes time due to the latency of the entire link. If you really want to understand it, go look up "bandwidth delay product."

SO - changing one element (making the server faster, eliminating the VPN portion of the network) will only address a tiny fraction of the problem.

As has been suggested -- look for a virtualization solution that only does screen scraping. Windows Remote Desktop, Citrix, VNC. You can easily build a virtual client hoster using VMware (free) and WIndows XP Pro (running Remote Desktop) that will sit right beside the server -- and be done with it. The HW is cheap; the O/S will be the biggest expense.

By the way, one poster suggested that VNC does not provide encryption. This is correct ONLY for the free/personal version. VNC enterprise provides encryption, as does Windows Remote Desktop.