Diagnose a slow FileMaker portal with a repeatable measurement

1. Define the slow action

“The portal is slow” can mean opening a layout, changing its parent record, scrolling or waiting after an edit. Choose one action before changing the file. For this exercise, measure switching from project P02 to P01 until the portal’s visible rows are rendered and usable.

Use a disposable desktop FileMaker Pro practice file. Record the exact client version, operating system, layout, window size and row count. If it is hosted, also record server version and whether the client is on a local network or remote connection. Local-file and hosted measurements answer different questions.

The worksheet intentionally contains no timings. Measure your environment. A published number from another machine would not establish how much faster your layout will become.

Download the blank benchmark worksheet ↓

2. Use a dataset whose membership you can check

Create Projects with ProjectID and Name (Text). Create Tasks with TaskID, ProjectID, Status and Title (Text), and Sequence (Number). Relate Projects::ProjectID to Tasks::ProjectID. Add P01 “Cedar” and P02 “North” manually.

Two CSV files provide alternative task volumes. Import one into an empty Tasks table as new records, using its heading row and matching fields. Use separate practice copies for the two sizes; do not import both into the same baseline.

Download the 200-task fixture ↓

Download the 2,000-task fixture ↓

Each project has its own task IDs. Even Sequence values are Open; odd values are Closed. The fixtures make correctness inspectable: P01 must never show a P02 task, and an Open-only view must exclude odd sequences. IDs are fictional inspection keys, not a production key-generation strategy.

3. Start with a minimal portal

Duplicate a Projects layout in the practice file. Use a related-record portal with ten visible rows and scrolling. Show TaskID, Sequence, Status and Title. Begin without a portal filter, sorting, decorative objects or additional calculation fields. Verify the relationship and field occurrences before timing anything.

Record the first P02-to-P01 visit after opening the client as a first-visit observation. Then repeat the same round trip five times and log those warmed runs separately. Reopening a client does not prove every server or operating-system cache is cold, so do not label this a controlled cold-cache benchmark.

Keep measurement endpoints consistent. A stopwatch is coarse for short actions; a screen recording can help identify first interaction and completed rendering. A script timer alone may end before painting is visible. Use one method throughout a comparison and state its limits.

4. Change one factor at a time

Restore the baseline before each variant. If you investigate an existing app, document the exact calculation or object you reintroduce; do not add an arbitrary slow calculation just to create a dramatic result. Keep window size, visible rows and data selection stable.

DB Services discusses layout work, calculations and network round trips as areas to investigate. Treat them as hypotheses, not guaranteed fixes. If a filtered variant shows less data, do not compare it as though it performs the same task as the unfiltered baseline.

For a later comparison between a portal filter and relationship criteria, first define the same target membership for both. Claris distinguishes display filtering from the full related set used by other calculations and summaries. A faster screen with a different total is not an equivalent result.

5. Compare repeated results with their spread

Sort the five warmed durations and use the middle value as the median. Also record the minimum and maximum. If the apparent change is smaller than the run-to-run variation or your timing precision, call the result inconclusive and gather better evidence.

Alternate baseline and candidate runs where possible, so a changing network or warmed cache is less likely to favor only one version. Repeat the comparison on the larger fixture, but do not extrapolate from 2,000 synthetic tasks to every production database.

Keep the raw observations. Do not fill blank cells with illustrative milliseconds and present them as measurements. A result should say what action, data and environment it describes, and whether the difference was consistent.

6. Accept the smallest change that preserves behavior

Recheck task membership, sort order, updates, empty projects and the intended user account. Inspect any totals separately from the displayed rows. A portal filter is a display feature, not record-level access control.

Do not turn an unstored calculation into stored data without defining how it remains correct when dependencies change. Removing a status field to gain speed is a product decision, not a free optimization. Keep the user’s task intact and retain a rollback copy.

Finished result: a repeatable observation, a named factor and an evidence-based decision to keep, reject or investigate the change. This article supplies a method and synthetic fixtures, not a claim of measured speedup. Native performance and interaction tests remain specific to your setup; Go and WebDirect require separate work.

References

• Claris: working with portals
• Claris: creating portals
• DB Services: performance optimization

Use a practice copy and verify the result in your FileMaker version. Product requirements and platform support remain specific to each product.