The design of your FileMaker solution may also be a factor. We’ve been providing Citrix XenApp and Microsoft RemoteApp workspaces (RDP protocol) access to our servers for over 10-years now. In our case, the FileMaker Servers and the RemoteApp servers streaming FileMaker are on the same VLAN within our infrastructure supplier, hence very fast bandwidth between these.
This arrangement allows for traditional FileMaker design to work fine. However, if you are going to use tables containing large number of fields, or use features such as summary fields, cross table sorting, replace field contents, etc. running FileMaker Pro locally on each computer, then the constraining factor of the user’s connection to the Internet can produce horrible results.
We (in the UK) have users based in Asia, Europe, USA and Australia, where latency is going to be at its worst, who operate at acceptable levels as only the RDP traffic is being transmitted/received. These users would not be able to work using a traditional FileMaker installation.
I’d suggest reading through Nick Lightbody’s ‘Performance core principles’ postings within this forum, starting at Performance core principles: 1. Unstored calculations before necessarily buying into bandwidth/latency only as the solution (both of which remain factors of course).
Our personal opinion is that FileMaker now consists of legacy features that should not be used in a WAN scenario, hence the coding can be somewhat more laborious to squeeze the features and speed out of the system. Saying that, if your server side scripts are taking that long to run, then perhaps the server is a factor as well?
Regards
Andy