Optimising Container Fields for best Performance in the Cloud

I've just been asked to improve the performance of a file that been moved from the desktop into the cloud. The problems occur on a list view that displays images.

This is an art/artist database. All of the images are stored in a single table and the related images are displayed in several list views.

The images table already does "optimisation." It has a number of calculation fields that generate smaller images using the GetThumbnail() function. These are all unstored calculations.

Question One: Is there any advantage at all? Doesn't the File->Manage->Containers options handle this situation? Should I ensure that the file option is Permanant Thumbnail storage and allow the server to handle this itself?

Question Two: is an unstored GetThumbnail() optimal? It seems to be swapping network bandwidth for CPU overhead.

Question Three: Would I get a benefit if I converted these calculation fields into auto-enter fields that generated a thumbnail and stored that for delivery?

1 Like

Malcolm

In haste due to what is going on here and not a direct answer to your questions, but first I spotted this in the v19.3.2 for Windows release notes:

In FileMaker Pro 19.3.2, PDF files are no longer streamed from the host. Instead, they are downloaded to a temporary folder on the user's local computer and displayed in interactive container fields. In most cases, this change in behavior won't be noticeable.

You don't mention whether the users are Mac or Windows, but I find the above very interesting, as I'd expect fully downloaded files to be slower than streaming from the host. We've quite a lot of experience with FileMaker and its use of temporary folders, which is particularly high when storing files in container fields. I would imagine a list of any form of images would not be 'cloud friendly'.

We often take hours or even days to achieve something that could be completed in minutes if we utilised all of FileMaker's features. But we'll avoid any additional TOs, calculation fields, cross table calculation fields, summary fields, etc. if we possibly can; purely for performance over the Internet.

Regarding question 3, we'd always opt for an auto-enter calculation field, providing it isn't cross table, with the added addition that these fields can be indexed.

My personal opinion is that you'll be struggling with list views with images over the WAN, particularly as you have no idea as to how fast a remote user's Internet connection is.

As for the remaining questions, other than repeating the official documentation, I don't have a lot to add.

Kind regards
Andy

Thanks adding your experience to this thread @AndyHibbs.

Our client has pushed a "built for Desktop" application into the cloud and I probably don't need to say that it's performance is miserable. The trick is knowing where to begin.

The app handles images so images are going to stay, but how do we handle them.

I'm hoping that @nicklightbody will have some tips.

I would test a WebDirect version. WebDirect basically renders (most) everything server-side then sends the results to the browser. I've seen webDirect be surprisingly faster, and also slower. Either way, it's useful data and might highlight a bottleneck.

Also, using WebDirect, you can use the Chrome or Safari profiler to see what is taking so long - this has a detail/granularity that you can't get from FMPro.

Also - what FMS and OS are you using?

Interesting suggestion. We've gone on-premise but there is a need for off-site access.

I think FMS should automatically thumbnail containers for you, without having to explicitly do so via calc fields.

We use WD and it definitely offers some performance benefits over FMP in our experience too.

If you're seeing big CPU spikes when FMS is generating thumbnails, you can indeed pre-generate and store thumbnails using something like imagemagick, which does so much more efficiently, but I suspect the issue is more network transfer related than thumbnail generation speed..