Servoy Forum

We have a customer with several branches in Far East, which are connected via a VPN or which are routed over several nodes of the customer's company network (e.g. first to Hub Asia, then to Hub USA, and from there to Hub Europe). The response time of the smart client is therefore currently not satisfying.
Are there any points which could to be taken care of, in order to speed up such connections, both from a network point of view and from side of Servoy development and Servoy AppServer?

HI Bernd,

I think the proper answer is 'host in the region of your customers'.
It's not for nothing most cloud companies have datacenters in several regions.

Hope this helps.

Hi Robert,
yes I also thought about that, it would be the last option in case all other measures fail. We have about 40 branches on one single Servoy solution (one tenant) for this group of companies, which has a lot of advantages regarding handling and transparency. As soon as we would split up this single-tenant solution, those advantages would be gone for the Far-East branches.

On the other hand, you can call today every internet page in the world and you do not have to wait more than seconds. So I can understand users when they ask why a database solution needs much more than that.

Thats why deploying the Smart Client over the WAN is generally a bad idea. Yes, it can be done, but is much more resource heavy and suffers over lower bandwidth or more hops to the server compared to the Web Client. The real solution is to migrate your app to the Web Client (or preferably the NG Client). I haven't developed any "new" projects in the Smart Client in many years. I still have some old customers running it, but nearly everyone is migrating to the browser.
I do have 1 large customer still running Smart Client over the WAN and it required some tuning of settings for their environment to maximize the speed. Still not as fast as Web Client, but you can only do some much with Smart Client over the WAN.

Any smart client application is a real client-server-application, meaning that many, many requests go back and forth. The most important figure to look at is latency ("ping time"). The next important measure might be query counts (not as much their timing, as long as that is not extremely slow). Less query counts, less slaggy the user experience.

Before splitting up the data to 40 locations I'd rather consider using the ng (or web) client in cases where the connection is simply not good enough (or even as a general deployment route). Since that client runs on the server, latency is less important.