Big performance hit after using variables to define FM external data sources

[Kent Searight]

I have a vertical market solution that requires database file names to be specific to the customer because I have multiple customers set up on a server (SBA licensing). I set up external data file naming using variables because that would save me some time when I update customer files to new version, i.e., I wouldn't have to use FM Developer tools anymore to rename them. It worked great ... until ... I tested running some of the more resource intensive scripts, some of which may have almost 100 records open and uncommitted at a time in complicated transactions.

They've been setup to run as PSOS and it's worked out very well for almost 2 years now. The average time for these transactions has been around 2.7-3.8 seconds (15 or so records modified or created for the average transaction) connected to a remote AWS EC2 Ubuntu instance.

But the elapsed times have at least doubled with dynamic data source naming. The session startup script that runs on server took about .1 seconds, now it takes over .2 seconds. I kind of expected that since more is happening at the beginning of a session (data sources need to resolve), but the surprise came when I looked at the elapsed times for the transactions after the session start script ran. The typical transaction that took a few seconds now takes 7-11 seconds. I compared two sets of solution files on the same server using the same data multiple times and the files with dynamically named data sources are consistently taking much longer. I had expected that once the files resolved their connections to each other after the session startup script, there wouldn't be any difference in performance, but there is.

Everything is running on latest versions of Pro, Go and Server, and the server OS is Ubuntu 18.04 (t3.xlarge) w/ separate drives for hosted files & backups. Has anyone else run into this problem? If so, did you figure out a solution?

I'd really like to use dynamic data source naming, but if I can't solve this performance issue it's a deal breaker.

Thanks in advance.

-Kent