I've finally created a database design report for my eight year old database! Quite a few errors (see attached). Can anyone suggest which element I should tackle first? There have been reports of sluggish performance so I want to tackle that first:

Many thanks

Collect info from the user users about what exactly is sluggish, otherwise you may be fixing things that don't need fixing.

Also use the FMS stats log and the top call stats log to help put some numbers to it.

While you wait for that, try to map out some of the usual suspects:

- messy file references

- layouts with more than 1 portal on it

- sorted relationships

- layouts with lots of unstored calcs and/or summary fields on it

- ...

Sounds good Wim, thanks! Re layouts with more than one portal - quite a few if not most of my layouts have more than one portal. Is this a problem in itself or are there certain ways to ensure good performance when using multiple portal? Or a limit for number of portals?

Same question for sorted relationships and unstored calcs/summary fields on layouts.

What would an example of a messy file reference look like?

Cheers

messy file references: any file reference that has multiple entries, some of which lead nowhere; multiple file reference entries that really point to the same file,..

 

Portals: understanding how a portal forces FMP and FMS to exchange data is crucial.  If you have multiple portals (and worse: of the portals are filtered, sorted or use a sorted relationship) then you have multiple of those interactions going on just to draw the layout.  

A lot of performance problems I have had to deal with over the years come from too much unneeded data being displayed on screens.

Hi Wim,

Would putting the portals in sliders, or popups improve the performance?

There's no mention of the server hardware, FMS config, network config or user count - these are also linked to performance issues.

Was there a point in time when the performance was considered OK?

That's why I recommended starting with the FMS logs; it keeps good track of the 4 traditional machine bottlenecks: processing power, memory, disk i/o and network i/o.  If those stats show strain on any of those then the consideration is: how much strain and is there a possibility of solving it with more horsepower. 

Thanks for all the  responses guys. Especially Wim's wise suggestion of finding out where it's slow. It turns out people are happy with the performance, I think this must be due to the server upgrade done months ago (i just assumed the slowness persisted).

MT!