What are you going to do if you are asked to test the performance of FileMaker Data API?

Questions
1

Hi, what are you going to do if you are asked to test the performance of FileMaker Data API, (not the Execute FileMaker Data API script step).

Something like comparing the time required to find out particular found set using scripting and data API?

or time taken of replacing field content on a particular field using scripting and data API?

Thank you for any advice.

2

Comparing to what?

3

Thank you. I think the processing time of normal scripting and Data API call.

or processing time of importing records through a script and data api call

4

Here migth someone who knows better what's happening under the hood but I would guess it's same as Perform Script on Server or Server Scheduled Script. So it's faster than standard script when data needs to be transferred between FMP client and FMS.

In my practical experience it's slower when comparing to standard web tech based api where backend does some data manipulation and sql database queries, but faster than running a FMP client script in WAN.

I have a plan in one case to use FMS as backend server without any FM user interface (no fmp or webd). Just have web app connected directly to data api.

1 Like
5

Hold your horses... that statement only applies in certain situations and CANNOT be stated as an absolute.

It will only be true IF the server has the spare capacity to perform the task. It will always test faster if you're the only one on the server while developing. If you have a marginal server (low-end Mac Mini?) and a decent load on the server (# of users, whatever taxing things those users do, schedules, other user's PSoS sessions,...) then the server may not have the capacity and the whole thing can end up being slower (sometimes significantly so) than letting the client do it.

If you want to use PSoS then the deployment choice becomes a lot more important than it usually is. I can't tell you how many solutions have been brought to us for fixing where PSoS was just used wildly under the assumption that 'it will be faster'.

Also: it complicates your code a fair bit because. you can't just assume that the FMS scripting engine is available. You need to error-trap and handle that. What do you do if the server can't do the task? Loop and wait a bit? How long? Back out of the scripted process? Turn around and let FMP complete the task?

5 Likes
6

I think you need to give us more background info. What is it really that you are considering doing? Calling the Data APi from inside a FM solution? From Outside?
It feels like you are considering some sort of fundamental architecture choice and it would be good to know exactly what you are considering instead of us giving you anecdotal performance evidence of some small piece of functionality that you will then use to validate your choice.

4 Likes
7

@WimDecorte is correct. PSOS speed will depend also on use case. But it will make less transferring of data when loading records and layouts.

Like everything with FileMaker, context matter (in db schema and layouts as well as solution and its use cases).