After attending Ray Cologon's stimulating FM13 Masterclass in London this February Alan Stirling and I had a discussion about the fastest means in Filemaker 13 of undertaking various operations. The result of which was we decided to build a FM Performance Data Server to which our various solutions and Apps could automatically upload the performance data we collected for comparison.
Our logic was that if we could see how long on average - for example - specific record creation and deletion techniques took to complete - we then had good baseline data from which to judge and improve our designs.
This has enabled us to be pretty confident about how fast some things can be expected to be in specific environments and in particular comparing FMP over WAN with FMGo and FM WebDirect and comparing server side scripting with the traditional client side stuff.
So now - in order to benefit our whole community with this tool - on the basis that the more data we collect the more we will all learn - and everyone should have a clear idea of what is normal performance and what is poor performance - we invite every Filemaker Developer to join this open project - FOC.
Attached you will find a small open example file which demonstates how to collect data, how to upload it to one of our Performance Servers and how to access the data on that server.
So you can now - if this interests you - download the example file and get started!
Please let me know on this list and/or email me on email@example.com whether you have any difficulty in incorporating the collection method - or other suggestions?
Here are some tips:
First - open the example and try it out:
- The first button creates a Data Record which action also creates an Event record
- The second button uploads all the Event Record(s) not previously uploaded - once the LogCentral file has been opened - the upload is fairly quick as record creation runs server-side.
- The third button opens LogCentral so you can find sort and analyse the data
- We normally call the Upload script in a solution as part of the logout / close procedure.
- It is essential to name the scripts on which you wish to collect data so that it is obvious what they do
- Use the xOnSvr function to record whether or not your script is running serverside
- Use the $$Version global in the Capture Environment script to pick up the current version name / no of your solution
- The example file includes the LogCentral server as an external data source - this obviously costs on performance when you startup your solution as it has to look for the EDS. Once you have the right bits of code in place and collection and uplaod working as intended we recommend that you remove the external datasource - disable the upload script and go collect data.
- Only add the path back into the EDS when you are ready to upload your data.
Second - incorporate the parts of the example file that collect and upload data into your own solution:
- Import the custom functions from the example file into your solution
- Add the External Data Source - LogCentral
- Copy the Events Table into your solution
- Copy the za4cts field into the TO used by your normal Ui layout
- Create a relationship from your normal Ui TO to the Events Table permitting records to be created through the relationship
- NB: Event record creation is through picking up a current TimeStamp, setting za4cts to that value then setting the timestamp field in the events table to that value
- Copy the Capture Environment script into your solution and call it from your startup script
- Copy the New Event script into your solution
- Set the variable $$startUTC to get(currenttimeUTCMilliseconds) at the beginning of any process on which you wish to collect data - at the end call the New Event script and then clear the $$startUTC value
- Copy the Upload Performance Data script, Open LogCentral script and Access LogCentral scripts into your solution
No doubt we can improve on what data we collect and on how it can be analysed - so your suggestions for improvement will be welcome - and in doing so you may be volunteering to under take such improvements yourself for thebenefit of all the users.
Here is what we currently collect and record:
Period that operation took to complete
Current Host TimeStamp
Operating System Version
Whether communication with the server is encrypted
Whether the file is encypted
The type of Device
The current device display scale
ConnectionType - a string describing the type of client and server - such as MacOnPC, iiPhoneOnMac or WDOnPC
User Account Name
Device Persistent ID
Current user TimeStamp
Your solution version
Whether or not server side scripted
Cheers, Nick Lightbody & Alan Stirling
The example file was replaced with v3