I've spent some time using Wireshark to observe my Sage 50 client communicating with the Sage Data Service.

My conclusion is that almost every action in Sage generates a huge number of small requests (of less than <500 bytes each), and receives a similarly huge number of replies from the data services. Loading my Transactions screen, for example, generates approximately 1500 HTTP request and reply packets in Sage.

Sage developers have therefore favoured a small packet model of data transfer, which means that latency is significantly more important than bandwidth. Latency can only be improved by moving your client nearer to the server so that the requests and replies have less equipment to 'hop' through.

Therefore a VPN connection will always be slower than a LAN connection due to the likely significant number of hops required to get from the home ISP connection through the various ISP interchanges into your VPN server and onto the Sage server.

This can be easily seen using a standard tracert request to your Sage server using both LAN and VPN pathways. In the real world I've observed 20-30 hops, and about 70ms latency time, to my Sage server when using a VPN connection from my home address, whereas it is only one hop and 1-2ms latency when using my LAN connection. As a result, my Sage VPN access runs significantly slower than when using LAN, despite the fact that the bandwidth available over the VPN (approx. 1Gb/s symmetrical) is identical to my LAN connection (also 1Gb/s). Lack of bandwidth is absolutely not the issue.

I'd imagine that the Sage 50 and the Sage Data Service could be improved by packaging its requests and replies into one larger bundle. Without the overheads associated with generating each packet, available bandwidth would become more important than latency.

I guess this is why Sage Drive was developed because it means that all requests and replies can be carried out on local data without any equipment to hop through. It's a shame, therefore, that Sage Drive is so poorly developed and prone to crashing its server, otherwise I'd have everybody using it, even on the LAN.

Just a small corrolary to my investigation above.

Despite my previous reservations, we are now using Sage Remote Data Access (formerly Sage Drive) for all office and home users.

Speed of access is super-fast and identical wherever the user is located because Sage is working with local data, and although we experience occasional (once every few weeks) data-sync issues, they are usually resolved by telling Sage to pull a fresh copy of data on the affected client.

There is a secondary benefit too - now that no users are accessing our Sage server directly on our LAN, I can potentially move it to a cloud server. This will remove the final piece of hardware from our server room, so I have planned to do this in the next few months.

In answer to the OP and how to improve VPN access, I'd recommend binning your VPN altogether and simply put all remote users on Sage Remote Data Access.

Hi Tyron

I'm glad that the Sage Remote Data Access is working well for you, but I still think that using Windows RDS into a Windows server on a fast broadband link is safer and more reliable. Especially as the number of users on Sage RDA increases - which in my experience greatly increases the potential for data sync issues. And, of course, you are relying on the robustness and reliability of the Sage RDA servers, and outages are far from unknown.

And a further observation. Sage RDA seems to work fine if a small number of users are actually posting transactions, while the majority of users are just viewing, or reporting, on the data. There is obviously less chance of update and sync issues if not too many users are posting.

And a further observation. Sage RDA seems to work fine if a small number of users are actually posting transactions, while the majority of users are just viewing, or reporting, on the data. There is obviously less chance of update and sync issues if not too many users are posting.