Skip navigation
All Places > FileMaker Platform Resources > Blog

WAN performance can be difficult to measure and improve. Your solution works great in the office, but when used outside your network, it is slow. Why? How can you make it better? This is the topic of many community  postings and DevCon sessions over the years. Since network latency is often a significant factor in slow performance, the collective wisdom is to “send less data over the network”

 

Sounds simple, right? “If I could get rid of my client’s data, this system would be blazing fast!” Now is the time to really think about why data is moving over the network, and then determine if it is really necessary at the time it is being done. Time to get creative.

 

The general idea is to remove as much related data as possible from being displayed or used on your layout. We know you will have to download the data for the table occurrence on which the layout is based, but you may have unnecessary portals, or unstored calculation fields which use related data, conditional formatting which refers to related data, etc.

 

Remember that even if you refer to only one field in a related table, the ENTIRE record is downloaded to the client.

 

Side note: when navigating to a layout and performing a find in a script, always enter find mode prior to the Go To Layout script step. This will prevent FileMaker from downloading the first 25 records of the table on which the layout is based.

 

We in FileMaker IS&T (the “eat our own dog food” group) have developed a little Mac-only client-based utility which helps measure and store the amount of data going to and from the FileMaker Server. We use Network Monitor.fmp12 to measure the effects of changing schema and layouts on network performance and it is proving to be invaluable in learning where we use related data and perhaps do not need to.

 

 

34FD087B-EB42-46C6-B051-7454C6223AAA.png

 

The usage of the tool is simple:

 

  1. Open Network Monitor.fmp12 and click Quit and Clear Cache. This will delete FileMaker’s local cache file so that data does not skew the results of the next operations.
  2. Open your solution and get to the point at which you wish to begin measuring the data flow with the FileMaker Server. I often enter find mode and go a layout.
  3. Click Start in Network Monitor.fmp12.
  4. Perform some actions in your solution (e.g. perform a find, navigate to another layout, etc.).
  5. Click Stop in Network Monitor.fmp12.
  6. View the results.
  7. You may optionally wish to store the results with a description of what you did. Use the log to compare results over time, after you’ve made tweaks in your solution.

 

 

The tool only measures data size, not speed. Remember there are other factors which will also affect speed, such as client-side sorting, graphics rendering, script triggers, etc.

 

The tool is totally open for you to learn from, update and enhance for your own use.

 

Good luck!

 

Download NetworkMonitor.fmp12 at the bottom of this page.

 

 

UNDER THE HOOD

 

When NetworkMonitor.fmp12 is opened, it exports 2 shell scripts and 1 compressed AppleScript into a temporary directory to be used by the solution.

 

The shell scripts use the nettop command, which outputs a list of processes that have active network connections. The data is displayed as a number of bytes in and bytes out over the network from the time that each process was launched.

 

When the Start button is pressed, the values of the in (using the ‘nettop_in.sh’ shell script) and out (using the ‘nettop_out.sh’ shell script) data values are stored in global fields.

 

When the Stop button is pressed, the same data values are grabbed and stored, and then the difference is calculated to get the total change in data from when the Start button was pressed.

 

The AppleScript is used to clear the cache. The AppleScript application is unzipped into a temporary directory and must be run as an Application to allow it to close FileMaker completely and then clear the cache files. The AppleScript named ‘clear_cache.app’ first gets the file path of the file which is stored in the active_filename_glob global field when the  script is run. This is so the file can be reopened after the cache is cleared and works whether the solution is hosted or local to the client. The script then closes FileMaker completely and then deletes the entire cache folder for FileMaker. Then using the file path reopens the solution.

 

The file is completely open so you can customize it for your own use.

 

We look forward to your comments below.

 

 

Jeff Benjamin

FileMaker IS&T

 

Gabriel Lewis

FileMaker IS&T Intern

 

 

 

============================================================================================================

By downloading and using Network Monitor you accept the following license terms:

 

Network Monitor License

 

Copyright © 2018  FileMaker, Inc. All rights reserved.

 

License Grant. FileMaker, Inc. grants you a non-exclusive limited license to use Network Monitor (“Software”) with a licensed copy of FileMaker software solely to view/store the amount of data transferring over TCP port 5003.

 

Intellectual Property. FileMaker owns all rights to the Software, including intellectual property rights therein.

 

No warranty. THIS SOFTWARE IS PROVIDED BY FILEMAKER, INC. ''AS IS'' AND WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL FILEMAKER, INC. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

 

Indemnity. You will indemnify and hold FMI harmless from any and all claims, damages, losses, liabilities, costs and expenses (including reasonable fees of attorneys and other professionals) arising out of or in connection with your use of the Software.

Export Law Assurances. You may not use or otherwise export or re-export the Software except as authorized by United States law and the laws of the jurisdiction in which the Software was obtained. In particular, but without limitation, the Software may not be exported or re-exported (a) into any U.S. embargoed countries, or (b) to anyone on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce's Denied Person's List or Entity List. By using the Software you represent and warrant that you are not located in, under control of, or a national or resident of any such country or on any such list. You also agree that you will not use the Software for any purposes prohibited by United States law, including, without limitation, the development, design, manufacture or production of nuclear, chemical or biological weapons.

============================================================================================================

The worldwide Solutions Consulting team at FileMaker, Inc. would like to share some of our favorite FileMaker 17 Platform features through a series of feature exploratory files. In this post, we’ll look at portals for master-detail layouts.

 

The master-detail interface is one of the most commonly used design patterns in today’s apps. In a master-detail interface, a list of records is displayed alongside the details of the currently selected record. We see this pattern in apps like Mail and Contacts.

 

Many of us know that it has been possible to do this in the FileMaker Platform, but it’s an advanced technique that even experienced developers struggle to set up.

 

New in the FileMaker 17 Platform, portals can now display records from the current found set, making it possible to create master-detail layouts in one step.

 

Please download the file and share your comments and questions here.

FileMaker Server is the true cornerstone of any app deployment. Big or small.

 

That has been the driving factor behind my desire to get very familiar with all of the FileMaker Server features, and it is a belief that I have been trying to convey while speaking at most of the DevCons over the past 17 years.

 

When I got started back with FileMaker Server 3, the Admin Console was almost non-existent, it was a plug-in that was used through a simple FileMaker file. Over the years, as the FileMaker Server feature set got deeper and wider it became a Microsoft Management Console snap-in on Windows and a standalone app on Mac. Later it became the Java-based unified Admin Console that functioned the same on both platforms (FileMaker Server 9) and then with FileMaker Server 13 we had the web-based Admin Console.

 

FileMaker Server 17 delivers the next iteration of the Admin Console, and no surprise, like with the other iterations in the past, it is different than its predecessors in many ways.

 

One of its stated design goals was to lower the barrier for installing FileMaker Server and be up and running quickly. That goal was achieved in spades. There are fewer decisions to make up-front and fewer steps to go through during the installation process.

 

Visually the Admin Console looks very different, closer to what the FileMaker Cloud Admin Console looks like. Under the hood it uses a completely different back end that promises to be more streamlined and lightweight. Under the hood it also uses the all-new FileMaker Admin API.

That Admin API is also exposed to us so that we now have three ways of interacting with our FileMaker Servers:

- the new Admin Console

- the new Admin API

- the updated Admin CLI

 

In fact, you will find yourself using the Admin API and/or the Admin CLI often; a number of configuration settings are only available through the API and CLI, such as:

- modifying the database cache

- modifying the progressive backup interval

- enabling the usage statistics log and the client stats log

- disabling the default midnight backup

 

No doubt some of these changes and the fact that adjusting those listed settings requires the use of the API and CLI will upset some people. The good news is that we are already seeing tools appear that fill those gaps. Tools built by community members that use those Admin APIs and CLIs exactly as they are meant to: to craft the tools that work best for you.

 

Together with another long-standing member of this community, Steven Blackwell, I have authored three extensive white papers to assist you through these changes:

FileMaker Server 17 Admin Console

They include a complete side-by-side of the old FileMaker 16 Admin Console and the new FileMaker 17 Admin Console, and also a full matrix of what settings are available across those three admin touch-points: the console, the API, and the CLI.

 

This year you will find me once again speaking at DevCon on the various features and changes in the FileMaker Server product, including a very cool demo of the FileMaker Data API, the newest member of the FileMaker Platform.

 

And as always, add your product feature requests and ideas: Product Ideas

so that they can be voted on by the community. Recent years have shown that ideas with lots of votes do get considered and implemented.

This is my first blog post in the community, so I thought I would just share how I became interested in the FileMaker platform. So, here goes...

 

I was working as the director of an it department. The company I worked for had locations in Oregon, Washington, and California. They were using an old 4D database to manage much of their day-to-day business operations. Every time we needed something updated, it was difficult to find a developer and the cost was at least $4000 for any small change. I hated it and wanted something similar that worked better, had a larger developer community, and would be more cost effective.

 

I worked with FileMaker in the late 90's on a job and recalled how much I liked it as an end user. So, I called up a developer in Portland, Oregon and the rest is history. The developer was Matt Navarre, who is well known in the FileMaker world. We talked for almost an hour and I threw many different scenarios at him.  I think what impressed me the most in my initial conversation with him was that his answer to all my questions was yes, it could be done with FileMaker.

 

After this, I was sold. We put together a proposal for me to pitch to the senior management at my company. I was very involved from start to finish on this complex database solution to replace our old 4d database. As a result, I became more interested in the FileMaker platform and began taking some classes through Lynda.com (Chris Ippolite's courses). I grew in confidence that I could use FileMaker to solve many other workflow problems in the company I worked for. I built 5 different FileMaker applications for this company.

 

I'm excited to find some work and begin doing FileMaker on a full-time basis. If you're looking for a thoughtful, organized, and hard working FileMaker developer, please send me a message! Below is a link to a YouTube video I made that showcases some of my work in layouts, scripting, and schema. I hope you'll check it out and tell me what you think. Thanks!

 

Filemaker Work Sample Screencast - YouTube