sal88 Posted August 20, 2017 Posted August 20, 2017 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
Wim Decorte Posted August 20, 2017 Posted August 20, 2017 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 - ...
sal88 Posted August 20, 2017 Author Posted August 20, 2017 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
Wim Decorte Posted August 20, 2017 Posted August 20, 2017 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.
Lee Smith Posted August 20, 2017 Posted August 20, 2017 Hi Wim, Would putting the portals in sliders, or popups improve the performance?
IdealData Posted August 21, 2017 Posted August 21, 2017 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?
Wim Decorte Posted August 21, 2017 Posted August 21, 2017 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.
sal88 Posted August 22, 2017 Author Posted August 22, 2017 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!
Recommended Posts
This topic is 2911 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now