It’s only slow the first time!

As developers, this is a common phrase we hear from our users who have hosted solutions. I’ve seen enough DevCon Under The Hood sessions to know this is because data needs to be downloaded to the client temp files before a process can proceed. Once the data has been downloaded, subsequent processes are as fast as a local solution. Even on a good LAN this experience can be quite stark. A common example is ExecuteSQL: since it’s a client side operation, all the referenced tables need to be downloaded to the client before the query can be processed.

PSOS to the rescue…well maybe

The obvious answer would seem to be to switch the operation to PSOS (Perform Script On Server) so no downloading is required. The problem is that although it will be faster than the first time the query is done from the client, it will never be as fast as those subsequent client queries. In other words, that downloaded data is the client’s friend, and giving that up for the sake of the first query may not provide the best overall experience for the user. Additionally, server side scripting is not an unlimited resource and if too many operations are shifted from the client then performance issues may crop up elsewhere. PSOS may be the answer, but in general, I take this on a case by case basis.

Behavior can be unintuitive

I recently ran into one of these situations that caused me to scratch my head a little and reminded me that this behavior can show up in unexpected places. The client reported that he was experiencing a first time slow down when editing a field. I assumed I had some script trigger attached that was running some kind of SQL that was the culprit, but when I looked, there were no triggers. I knew this field was at the bottom of a lot of dependent calculations, but why was it just slow the first time? I associate this behavior with downloading data from the client, but where was that happening here? We’re just editing a field?

After some investigation and experimenting, I believe the issue is with the calculations that this edit affects, but it’s the other dependent values in these calculations. In this case many of the dependent calculations require an average value that’s based on a table of a few hundred thousand records. In order for the edit to complete, that entire table needs to be downloaded and the dependent calculations need to be evaluated on the client before they are updated on the server. In order for this to happen, all the dependencies are needed on the client side. In my experiments I witnessed this behavior in action, and saw that the dependent calculations were updated before the record was committed. In order for this to happen, the client needs that average value.

These edits were not done in batches, so making the subsequent ones faster didn’t add much value. Because of this, I added a simple routine to set the value on the server. The user enters the value into a global and then an OnSave trigger calls a script on the server to set the field to the global (passed as a parameter). This works great and solved the issue and seems like an appropriate use of PSOS.

Interesting behavior for sure, but does this sound right? I’m curious if someone has an alternate theory for this behavior and if I’m missing another explanation.

2 Responses to Chasing FileMaker Client-Server Performance

  1. Jeremy says:

    Another approach might have been to change how that average was calculated: create a table to store the average (and other other statistics calculated over the same records), and updated it incrementally (without checking all the other source records) every time a source record gets edited, added, or deleted. This way, calculations using the average can access one record instead of many. It’s more programming work than your solution, but less work on the computers’ part.

  2. Lisette says:

    I’ve just had a similar situation arise, and switching to PSOS allowed me to make a quick fix. While I agree with Jeremy that another approach might resolve my situation, I could not have done so as quickly. If nothing else, this has bought me the time to come up with a bulletproof alternative to 4 complex calculations involving related data.

Leave a Reply

Your email address will not be published. Required fields are marked *

Share →
DOWNLOAD
DayBack Calendar
DayBack's 30-day trial is unlocked so you can customize it and integrate it with your files.
Download DayBack and we'll send you a couple short emails with tips on how to modify it and use some of the coolest features.
Thank you! Please download: DayBack Calendar
Need More?
SeedCode tips & example files in your inbox
Need More?
SeedCode tips & example files in your inbox
Want More?
Be the first to see articles and tips like these
DOWNLOAD
TimeZync
Download TimeZync and we'll send you a couple short emails with tips syncing your FileMaker Go files.
Thank you! Please download: TimeZync
Want More?
Be the first to see articles and tips like these