Call Time - Best practice? Optimizing hooks and performance

Support
1

I was wondering if there was a best practice or call time in ms that we should be shooting for with our payloads to provide the best user experience. there are times when I need to grab larger data sets and see times of 6000 ms (not ideal). wondering if there are any established numbers that should be considered “optimal” for page loads, etc.

2

Great Question
First, reasons to optimize:

1. Faster better experience for user
2. lower CPU time allowing higher throughput
3. Reduced data if using DAPI ( not usually an issue)

Optimizations come in four areas mainly:

Payload size - call time
BF tries to reduce some data by default but there is a ton more you can do.

  • In hooks where you need just an id or small data, don’t send the whole model payload, you can reduce what you send using the modelFilterKeys setting. See docs.
  • For apps that had a lot of data in things like tables, you can cache the data in the browser with a new caching feature. Then your front end can check for that and use and maybe later call the server for latest.
  • The call time in the inbox only measures the time FMS is processing the script, but there is also conversion overhead from converting large data sets too. Smaller is better.

Reduce FMS processing of code

  • I often see poorly written code that has deep iterations causing long hook times. Write tight, clean performant code. FM best practices come in here
  • For things that take a long time, consider running as PSOS and returning the control back to the browser.
  • Regular BF hooks run under the Web Publishing Engine ( WPE) so you can call PSOS too. We often do this for slower processes like sending emails and calling external API’s.
  • Save the whole JSON blob, if you are just saving a record thats partially filled, consider saving the entire model vs normalizing the data. Most use cases just want completed data anyways.
  • Build a simple cache in FM. Have a big slow chuck of related deep JSON that doesn’t change often? Just cache it in a key as a single field and fetch that. When you change the data, just call your rebuild cache routine.

BetterUX

  • this is often ignored, but a faster easier UI is a faster app. UX matters!
  • if you are waiting to reload a data table each time you visit the home page, why not either use a card modal for your detail page or cache the data?

In summary, less hook calls, less data and shorter hook times mean better system performance.

HTH
c